Talk:OpenRC: Difference between revisions

From Alpine Linux
(made the changes and replied to John3-16)
(1. Supporting Prabu's concerns re recent edits; 2. Discussion re "$ openrc -U" reverting to a certain runlevel; 3. Amended various root prompts back to user prompts)
 
(8 intermediate revisions by 2 users not shown)
Line 21: Line 21:


:: 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 {{Codeline|1=FAST_STARTUP=yes}} to Chrony page, i'm quite hesitant to touch pages where i lack knowledge. -[[User:Prabuanand|Prabuanand]] ([[User talk:Prabuanand|talk]]) 20:02, 8 August 2025 (UTC)
:: 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 {{Codeline|1=FAST_STARTUP=yes}} to Chrony page, i'm quite hesitant to touch pages where i lack knowledge. -[[User:Prabuanand|Prabuanand]] ([[User talk:Prabuanand|talk]]) 20:02, 8 August 2025 (UTC)
The below Note may add confusion to users. Please consider rewording or removal.
{{Note|The upstream OpenRC User Guide for user services considers [https://github.com/OpenRC/openrc/blob/master/user-guide.md#auto-starting configuring  pam] in the management of user service sessions;  as an experimental branch of OpenRC, this facility, including its autostart configuration, may be fluid.  Many Alpine Linux installations typically may not run pam.}}
* 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.
- [[User:Prabuanand|Prabuanand]] ([[User talk: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 [[OpenRC#PAM_support|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 [https://github.com/OpenRC/openrc/pull/723 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 [https://wiki.gentoo.org/wiki/OpenRC/Legacy_user_services outdated Gentoo wiki page] about legacy user services that furthermore had examined {{pkg|wlsunset}} when used as a user service in Wayland;  their current [https://wiki.gentoo.org/wiki/OpenRC#User_services 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 [[OpenRC#Command_usage|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 {{ic|rc-service}} and {{ic|rc-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:
'''Commonly-used OpenRC commands'''
Start, stop (or {ic|restart}}) a service, for example, at the boot runlevel (do not use employ the '<' nor '>'):
{{cmd|doas rc-service <serviceName> start boot}}
{{cmd|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 {{ic|default}} runlevel;  note that the '''default''' runlevel is assumed, so it does not need to be stated explicitly:
{{cmd|doas rc-update add <serviceName> default}}
{{cmd|doas rc-update del <serviceName>}}
List the current statuses of all services;  however, do not use {{ic|doas}} nor the equivalent command as root to display the statuses of any ''user service'':
{{cmd|doas rc-status}}
List the assigned runlevels of all services;  likewise, do not use {{ic|doas}} nor root to display the runlevels of user services:
{{cmd|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 [[OpenRC#Command_usage|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.
::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)
== 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)
== User Services -> Runlevels ==
Dear [[User:WhyNotHugo]], This section probably requires some rewriting.
* I'm not sure when this sysinit runlevel is used/required "mkdir -p ${XDG_CONFIG_HOME:-~/.config}/rc/runlevels/sysinit".
* in the command openrc -U $RUNLEVEL. Instead of $RUNLEVEL, consider using <> as [[Help:Reading#Placeholder|placeholder]].
* Will adding "exec openrc -U gui" to ~/.profile support both Wayland and Xorg? Shouldn't the Compositor startup file be used for this for wayland?  --[[User:Prabuanand|Prabuanand]] ([[User talk:Prabuanand|talk]]) 16:13, 5 September 2025 (UTC)
:I just now tested adding "exec openrc -U gui" to ~/.profile and i got locked out with "XDG_RUNTIME_DIR unset". Only after removing this, i could login to tty. Sway too did not start with this option. Here are my [git.sr.ht:~prabuanand/dotfiles dotfiles] for reference. -[[User:Prabuanand|Prabuanand]] ([[User talk:Prabuanand|talk]]) 16:55, 5 September 2025 (UTC)
::Dear [[User:WhyNotHugo]], Thank you for your excellent contributions to Linux, and to Alpine Linux in particular. I support [[User:Prabuanand|Prabuanand]]'s excellent and extensive impressions/observations above however, including those further above in the 'Warning in PAM support' discussion.  I would be grateful for your input about them.
::Additionally, I suspect that two further points of guidance in your edits warrant review or elaboration on the wiki page:-
::*Your claim that '''sysinit''' is the default level;  please elaborate why '''default''' would not be the default runlevel here, for my better understanding and for the sake of newcomers to Alpine Linux's wiki. 
::*Note also that your instruction did not revert the runlevel back to '''sysinit''' on my system, even with the user ('''-U ''') switch:  {{Cmd|$ openrc -U}}
::*Your edit proposing a command to revert to the sysinit runlevel appears to run contrary to the guidance [[OpenRC#Runlevels|currently in the wiki]], that ''"sysinit always runs when the host first starts and should not be run again."''
::Thanks again for your help addressing our concerns. [[User:John3-16|John3-16]] ([[User talk:John3-16|talk]]) 17:43, 12 September 2025 (UTC)
Dear [[User:StruanR]], 
I am grateful for your improvements of the wiki, kindly continue them!  Please note that certain edits, however, changing a root prompt to a user prompt, were in various cases inaccurate, and I have reverted those.  Perhaps the wiki could be made clearer that to modify ''system'' services or runlevels, one generally requires a root prompt or doas/sudo;  to display/check those, a user prompt may suffice.  Note, on the other hand, that to modify ''user'' services (using the '''-U''' switch), a root prompt or doas/sudo would not generally be used.  I hope this helps.
Your other edits were helpful, thank you! 
I took the chance to amend some previous passages made by other helpful contributors while I was at it.  Please continue helping out with the wiki! [[User:John3-16|John3-16]] ([[User talk:John3-16|talk]]) 17:43, 12 September 2025 (UTC)

Latest revision as of 17:43, 12 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:

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:

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.

Note: The upstream OpenRC User Guide for user services considers configuring pam in the management of user service sessions; as an experimental branch of OpenRC, this facility, including its autostart configuration, may be fluid. Many Alpine Linux installations typically may not run pam.
  • 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 and rc-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:

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.
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)

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)

User Services -> Runlevels

Dear User:WhyNotHugo, This section probably requires some rewriting.

  • I'm not sure when this sysinit runlevel is used/required "mkdir -p ${XDG_CONFIG_HOME:-~/.config}/rc/runlevels/sysinit".
  • in the command openrc -U $RUNLEVEL. Instead of $RUNLEVEL, consider using <> as placeholder.
  • Will adding "exec openrc -U gui" to ~/.profile support both Wayland and Xorg? Shouldn't the Compositor startup file be used for this for wayland? --Prabuanand (talk) 16:13, 5 September 2025 (UTC)
I just now tested adding "exec openrc -U gui" to ~/.profile and i got locked out with "XDG_RUNTIME_DIR unset". Only after removing this, i could login to tty. Sway too did not start with this option. Here are my [git.sr.ht:~prabuanand/dotfiles dotfiles] for reference. -Prabuanand (talk) 16:55, 5 September 2025 (UTC)
Dear User:WhyNotHugo, Thank you for your excellent contributions to Linux, and to Alpine Linux in particular. I support Prabuanand's excellent and extensive impressions/observations above however, including those further above in the 'Warning in PAM support' discussion. I would be grateful for your input about them.
Additionally, I suspect that two further points of guidance in your edits warrant review or elaboration on the wiki page:-
  • Your claim that sysinit is the default level; please elaborate why default would not be the default runlevel here, for my better understanding and for the sake of newcomers to Alpine Linux's wiki.
  • Note also that your instruction did not revert the runlevel back to sysinit on my system, even with the user (-U ) switch:

    $ openrc -U

  • Your edit proposing a command to revert to the sysinit runlevel appears to run contrary to the guidance currently in the wiki, that "sysinit always runs when the host first starts and should not be run again."
Thanks again for your help addressing our concerns. John3-16 (talk) 17:43, 12 September 2025 (UTC)

Dear User:StruanR, I am grateful for your improvements of the wiki, kindly continue them! Please note that certain edits, however, changing a root prompt to a user prompt, were in various cases inaccurate, and I have reverted those. Perhaps the wiki could be made clearer that to modify system services or runlevels, one generally requires a root prompt or doas/sudo; to display/check those, a user prompt may suffice. Note, on the other hand, that to modify user services (using the -U switch), a root prompt or doas/sudo would not generally be used. I hope this helps. Your other edits were helpful, thank you! I took the chance to amend some previous passages made by other helpful contributors while I was at it. Please continue helping out with the wiki! John3-16 (talk) 17:43, 12 September 2025 (UTC)