Talk:OpenRC: Difference between revisions
Prabuanand (talk | contribs) (suggested changes have been made) |
Prabuanand (talk | contribs) (→Warning in PAM support: new section) |
||
Line 67: | Line 67: | ||
::Thank you. [[User:John3-16|John3-16]] ([[User talk:John3-16|talk]]) 21:44, 11 August 2025 (UTC) | ::Thank you. [[User:John3-16|John3-16]] ([[User talk:John3-16|talk]]) 21:44, 11 August 2025 (UTC) | ||
::: Thanks once again for the detailed suggestions. Hope i've done everything as suggested. Please make necessary amends, if i have missed out something. Highly appreciated. -[[User:Prabuanand|Prabuanand]] ([[User talk:Prabuanand|talk]]) 10:03, 12 August 2025 (UTC) | ::: Thanks once again for the detailed suggestions. Hope i've done everything as suggested. Please make necessary amends, if i have missed out something. Highly appreciated. -[[User:Prabuanand|Prabuanand]] ([[User talk:Prabuanand|talk]]) 10:03, 12 August 2025 (UTC) | ||
== Warning in PAM support == | |||
Dear User:WhyNotHugo, I'm not sure about the need for warning in the PAM support section. I have been using User services with PAM support for the past few months without any issues and i have not seen any bug reports filed regarding this. btw:i'm using pamrundir and i tested dwm with the manual XDG_RUNTIME_DIR script as added there. I believe Warning should be sparingly used in Wiki, if there are unresolved/known issues. - [[User:Prabuanand|Prabuanand]] ([[User talk:Prabuanand|talk]]) 15:59, 5 September 2025 (UTC) |
Revision as of 15:59, 5 September 2025
The Preventing slow services from delaying boot passage currently uses chronyd as an example of a service that may delay boot. The passage could be improved:-
1. There is another, simpler and safer method to prevent a slow startup by chronyd that could be listed first and avoids dealing with the expressed danger of editing /etc/inittab wrongly and its implied stunting of system boot.
The method has been suggested helpfully in various places:
- In the second paragraph of the file to be edited: /etc/conf.d/chronyd
- https://whynothugo.nl/journal/2023/11/19/setting-up-an-alpine-linux-workstation/#chronyd-blocks-at-startup
- https://gist.github.com/c0m4r/e38d41d0e31f6adda4b4c5a88ba0a453#NTP
The method is to edit /etc/conf.d/chronyd and to change the line FAST_STARTUP=no to FAST_STARTUP=yes.
2. Technically, chronyd is not a boot service but rather launches at the default level (rc-update add chronyd default), so the subheading may need to be improved. There is only one wiki page that links to that subheading, and it is in this very same OpenRC wiki page, so it should be easy to change the subheading title, say, from "Preventing slow services from delaying boot" to "Preventing slow services from delaying system launch" or ...system startup. The link is mentioned twice in this wiki page, so those passages could be reviewed:
- https://wiki.alpinelinux.org/wiki/OpenRC#Stacked_runlevels
- https://wiki.alpinelinux.org/wiki/OpenRC#Configuration
Alternatively, an Include:Chronyd - Startup Speed Enhancement page could be started for inclusion here and wherever else (Any future Chrony page, for example) that would include the current inittab method and the FAST_STARTUP method. John3-16 (talk) 16:21, 8 August 2025 (UTC)
- Please note also that the external link about the inittab method, OpenRC: Start services after login prompt, is now broken. Please consider whether perhaps the reference/attribution is suitable, as it stands. John3-16 (talk) 16:33, 8 August 2025 (UTC)
- John3-16 (talk)
- Thanks for submitting a thorough feedback. Highly appreciated. I have fixed the external links and internal links and updated section heading as per your suggestion. Service chrony was meant to be example to explain the concept. For now i've removed the word chrony. Regarding adding FAST_STARTUP=yes to Chrony page, i'm quite hesitant to touch pages where i lack knowledge. -Prabuanand (talk) 20:02, 8 August 2025 (UTC)
The below Note may add confusion to users. Please consider rewording or removal.
- The experimental is already there "User services are currently experimental ". If necessary that can be highlighted.
- I request a rewording to tell user on what he's supposed to do for pam. In the current form, the Note does not help the user on how to proceed.
- Prabuanand (talk) 11:03, 11 August 2025 (UTC)
- - Thank you for your kind attention on the wiki. I have tried to address your concern by removing the note plus the reference to it under PAM support instead of elaborating on the upstream OpenRC configuration user guide passage regarding pam.
- - On a different topic, while hoping to keep the wiki a clear user guide, do we want to simultaneously reference more in-depth examinations about user services that may be significant to developers? For example, consider a possible closing passage under User Services, or under a new Further reading section, or perhaps in a briefer form under See also:
- 'For a more in-depth examination of OpenRC user services, consider useful discussions regarding DE-dependent (desktop environment) vs DE-independent environment variables discussed in an upstream thread about user services, and whether the variables ought to be passed on filtered (not in whole) or not. Other useful assessments were laid out in an excellent though now outdated Gentoo wiki page about legacy user services that furthermore had examined wlsunset when used as a user service in Wayland; their current User Services page adds further useful and more up-to-date contributions.'
- This passage could be left here for any further discussion or added to the wiki with or without any edits, as may be seen to be suitable; I am grateful either way.
- - Perhaps one should consider moving the paragraph about allowing parallel services into the section Preventing slow services from delaying system startup, as a subheading called "Parallel services". It could be placed after the introductory paragraph, "Services that take a while to start will block ...". This parallel services passage is not immediately relevant in its current location as the second paragraph about OpenRC configuration. It may simply appear there from early days in the preparation of the page.
- The suggestion that currently appears there could then be listed as a second subheading (after the "Parallel services" subheading suggested above), to be titled, say, "Async runlevel method", "Stacked runlevel method", "Inittab method" or as suitable.
- - Are we satisfied to keep the Command usage section where it is, deep down on this page, or would it be more pertinent to give command usage examples nearer to the introductory section of the wiki page, perhaps at the beginning of [OpenRC#Quickstart|Quickstart] table or immediately after it (retaining the Command usage subheading or not)? Perhaps this Command usage passage has suffered displacement from newer passages.
- This passage could additionally illustrate the most commonly used OpenRC commands at the beginning of the Quickstart section with a handful of complete
rc-service
andrc-update
command line instructions; otherwise, full examples of common OpenRC clis first appear in the disproportionally long User Services section, and OpenRC instructions are otherwise introduced quickly, with no complete cli example, in the current QuickStart table:
- This passage could additionally illustrate the most commonly used OpenRC commands at the beginning of the Quickstart section with a handful of complete
Commonly-used OpenRC commands Start, stop (or {ic|restart}}) a service, for example, at the boot runlevel (do not use employ the '<' nor '>'):
doas rc-service <serviceName> start boot
doas rc-service <serviceName> stop boot
Add or delete a service to/from the sequence of services that need to start automatically in future sessions at the default
runlevel; note that the default runlevel is assumed, so it does not need to be stated explicitly:
doas rc-update add <serviceName> default
doas rc-update del <serviceName>
List the current statuses of all services; however, do not use doas
nor the equivalent command as root to display the statuses of any user service:
doas rc-status
List the assigned runlevels of all services; likewise, do not use doas
nor root to display the runlevels of user services:
doas rc-update
- Alternatively, the above Commonly-used OpenRC commands passage, with or without any edits as may be seen to be suitable, could simply not be included.
- - The current passage in Command usage, "To view the command usage for all OpenRC commands (rc-update, rc-service, rc-status, openrc etc.) use the --help or -h flag [...]" could be moved into the Quickstart section instead of leaving it near the end of the page.
- - The Command usage section further contains a paragraph that is irrelevant to OpenRC: 'The busybox command equivalent for traditional GNU/Linux systems is as follows [...]'. This paragraph would be more relevant, if at all, for example:-
- In the BusyBox page, if suitable; or
- In the Comparison_with_other_distros 'Rosetta Stone' page, perhaps under a new heading there, say, Userspace commands or Command line instructions, seeing how, currently, there are only sections for Package management, Runlevel & Initscripts and Config files; or
- Being culled from this page.
- - The Command usage section further contains a paragraph that is irrelevant to OpenRC: 'The busybox command equivalent for traditional GNU/Linux systems is as follows [...]'. This paragraph would be more relevant, if at all, for example:-
- Thank you. John3-16 (talk) 21:44, 11 August 2025 (UTC)
- Thanks once again for the detailed suggestions. Hope i've done everything as suggested. Please make necessary amends, if i have missed out something. Highly appreciated. -Prabuanand (talk) 10:03, 12 August 2025 (UTC)
- Thank you. John3-16 (talk) 21:44, 11 August 2025 (UTC)
Warning in PAM support
Dear User:WhyNotHugo, I'm not sure about the need for warning in the PAM support section. I have been using User services with PAM support for the past few months without any issues and i have not seen any bug reports filed regarding this. btw:i'm using pamrundir and i tested dwm with the manual XDG_RUNTIME_DIR script as added there. I believe Warning should be sparingly used in Wiki, if there are unresolved/known issues. - Prabuanand (talk) 15:59, 5 September 2025 (UTC)