Skip to main content ↑ ↓
Topic: OpenRC User Services feature now available (experimental) (Read 1793 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

OpenRC User Services feature now available (experimental)

Version 0.60.1 of OpenRC - currently available in our Artix Linux repository together with pambase that also needs to be updated - introduces User Services as a new experimental feature.

There does not seem much documentation available on this topic yet, but this Artix Linux Wiki section might help in setting up and using.

Note: this feature is experimental, AND this document itself is a work in progress.

artist
Linux is simple; use Artix, or Submit Your System To Evil Malicious D(a)emons

Re: OpenRC User Services feature now available (experimental)

Reply #1 –
what is it useful for?

Re: OpenRC User Services feature now available (experimental)

Reply #2 –
Quote from: mrbrklyn – on
what is it useful for?

https://wiki.gentoo.org/wiki/OpenRC/Legacy_user_services#Last_words
https://wiki.gentoo.org/wiki/OpenRC/Legacy_user_services
https://wiki.gentoo.org/wiki/OpenRC#User_services_support
"Wer alles kann, macht nichts richtig"

Artix USE="runit openrc slim openbox lxde gtk2 qt4 qt5 qt6 conky
-gtk3 -gtk4 -adwaita{cursors,themes,icons} -gnome3 -kde -plasma -wayland "

Re: OpenRC User Services feature now available (experimental)

Reply #3 –
according to that it adds nothing that we don't already have with  ~/.profile and /etc/profile.  So what is the point of dragging this into an init process whose function is to bring up services according to run levels?

Re: OpenRC User Services feature now available (experimental)

Reply #4 –
It's useful for starting and controlling local user services like pipewire, mpd, transmission, etc.

Re: OpenRC User Services feature now available (experimental)

Reply #5 –
That doesn't make a whole lot of sense.  That is just moving programs that are user programs into the  init systems where they don't belong.  You have ./.profile and /etc/profile not to mention bashrc among other things.  init is for system programs that are universally needed in various run levels.  How is this not completely unnecessary complexity?  Why make such a left handed and ugly hack.

Re: OpenRC User Services feature now available (experimental)

Reply #6 –
I don't see what the issue is with choice? No one is being forced to use Openrc user services. Openrc are not trying to make the other methods of autostarting go away.

init is just starting programs which is what init does. This is just taking out the middle man whether it be a Display Manager, TTY, X or Bash etc if you choose for that to happen. 

So far I've implemented Openrc user services for the pipewire trio and it seems to be working well. Everything else I autostart or configure automatically as a user I decided to leave as is.

Re: OpenRC User Services feature now available (experimental)

Reply #7 –
Hacking user services with profiles is also somewhat ugly. It starts with every shell (or worse, instance of an specific shell, so the user has to fix things up if they switch, say, from bash to zsh), which means you need boilerplate to prevent spawning multiple instances of the same service or to recognize login types (so they're not spawned when, say, you SSH or su into the account instead of a normal login).

Really, user services reuse what makes inits good for system management (tracking services and starting/stopping them in bulk in reaction to a command) in a different context. Plus, they hook into PAM, so it reacts to the login itself (instead of relying on the coincidence that users or scripts call the shell often).

Re: OpenRC User Services feature now available (experimental)

Reply #8 –
<<Hacking user services with profiles is also somewhat ugly.>>


No it is the standard and you always know where it is.  Moving user space activities to init just breaks the standard and makes complexity where it is not needed.  And there is  zero benefit... at least nobody has pointed any out.  We don't need it to involve pam which itself is an ugly klug.

Re: OpenRC User Services feature now available (experimental)

Reply #9 –
Quote from: gripped – on
I don't see what the issue is with choice?

I don't agree with that.  You obviously never raised 6 kids and made dinner for them...

One case is remaining with the standard model.  The other is the choice to break the standard with unneeded complexity.  One thing I have learned in my 8 years in the US Army is that unneeded complexity is a  design flaw and  in that context ... kills  the wrong people.

I am trying to be diplomatic about this and not start a war.  I said my peace and now I am done.

Re: OpenRC User Services feature now available (experimental)

Reply #10 –
Quote from: mrbrklyn – on
You obviously never raised 6 kids and made dinner for them...
Offering choice to all six kids would involve the parent then have to cook six possibly different dinners all at the same time, in the present. Offering choice to the users of Openrc does involve extra work PRIOR to the choice being made by the user but does not involve extra work at the time the users choice is made. In other word it's not the same thing at all (I haven't raised six kids, only three).

I don't think anyone is going to die because of user services? At least I truly hope not.
You think user services are a bad idea. I think they are a reasonable idea but I wasn't desperate for them.
There is no drama ?

Re: OpenRC User Services feature now available (experimental)

Reply #11 –
Quote from: mrbrklyn – on
<<Hacking user services with profiles is also somewhat ugly.>>


No it is the standard and you always know where it is. Moving user space activities to init just breaks the standard

Then where is it? .profile? .xprofile? .xinitrc? .bashrc?

"You know because you set it up". Then it's not a standard (everyone's rolling their own thing) and it begs the question, why have an init system in the first place? Back in the early 80s, PID 1 just called an admin written /etc/rc file that started all the services the machine needed.

Plus, as gripped said, existing ways of autostarting programs aren't going way.

Quote
and makes complexity where it is not needed.

Init systems already have 99% of the complexity user services need. Looking at the code for runit or s6, which have had user services for longer than OpenRC, you'll find no special handling is needed for that, the separation happens naturally because of permissions. The only extra code needed is making the user services start up (be it via the "main" init system, profile files, DE autostart or PAM), and that's just hooking the login process (or something that happens alongside it) to a runlevel change.

This isn't like spending extra on groceries for six completely different dinners, it's more like a dessert that reuses the existing ingredients in a new way.

Quote
And there is  zero benefit... at least nobody has pointed any out.

The second paragraph on the wiki page that supposedly says there's no benefit over profiles or autostarting starts with:

Quote from: https://wiki.gentoo.org/wiki/OpenRC/Legacy_user_services
A process supervisor offers two main benefits [...] also offers minor benefits

For a concrete example, there's Pipewire -- user services (this or Turnstile) prevent the known bugs caused by the autostarted processes lingering after logout. Sure, I can add a bunch of pkill/killall to the startup script (like the old launcher script used to do), but that won't work well with shell profiles and it's exactly the kind of bulk process management init systems are supposed to help you with.

Quote
We don't need it to involve pam which itself is an ugly klug.

PAM is the right place for "spawn stuff upon login and stop upon logout" (and, for better or worse, a successful standard). The problem is in the execution, not in the concept of "customize what happens during login".

Re: OpenRC User Services feature now available (experimental)

Reply #12 –
Quote from: capezotte – on
PAM is the right place for "spawn stuff upon login and stop upon logout" (and, for better or worse, a successful standard). The problem is in the execution, not in the concept of "customize what happens during login".
I think I agree that PAM is the place to handle some / all of the per user services even though it's supposed to be mostly about authentication.

I use openbox and so far its autostart shell script is good enough for me. Its services die at openbox exit, but perhaps I'm only running things which cannot survive without X11.

 You mention that runit / s6 have had per user services, but I think runit at least doesn't seem to have a PAM based service startup for a user. Are there any pam modules for runit?

Re: OpenRC User Services feature now available (experimental)

Reply #13 –
Quote from: replabrobin – on
I use openbox and so far its autostart shell script is good enough for me. Its services die at openbox exit, but perhaps I'm only running things which cannot survive without X11.

Most user services do. I think PipeWire is the first major exception.

Quote
You mention that runit / s6 have had per user services, but I think runit at least doesn't seem to have a PAM based service startup for a user. Are there any pam modules for runit?

I meant to say they support the concept in general (s6 even comes with s6-usertree-maker), they don't have built-in PAM modules for that.

However, there's Turnstile. You can switch the backend from dinit to runit and have it handle user services, though, so far, there's no official turnstile-runit init script and only the dinit as user services manager is well supported on Artix with packaged scripts and stuff.

I'm using turnstile with dinit because of the better support, despite running s6 as PID 1.

Another option (though it's more work) is doing something like the "Legacy user services" article suggests for OpenRC: have a service with a "down" file that starts a runsvdir for your user, then make a pam_exec script that brings it up or down.

Re: OpenRC User Services feature now available (experimental)

Reply #14 –
hi. i wrote those patches, and to add some more context to the replies already present:

> according to that it adds nothing that we don't already have with  ~/.profile and /etc/profile.

it adds supervision, process management, dependency resolution. this is like saying "why use openrc, it adds nothing over sysvinit scripts!", no, it does.

> How is this not completely unnecessary complexity?

the "complexity" is using ~/.config/rc instead of /etc, and $XDG_RUNTIME_DIR instead of /run, that's it.

the reason openrc couldn't do this before is because the paths to directories and such were hardcoded.

the only bit of extra complexity here is a pam module that literally just starts the `user.$USER` service for you automatically.
if you want, you can forget about pam all together, it's optional, and manually calling `openrc --user` in a .profile file is fully supported.
 
Artix forum uses a single cookie to remember youOK