El jue, 26 feb 2026 a las 8:29, Laurent Bercot escribió: > > User services are a whole can of worms because they interact with a > lot of unsavory interfaces and an ecosystem that is pretty hostile to > policies it does not have full control over. I intend to study the > domain and make it easier for people to run user services with s6, but > that will not be in the short term.
Probably the most well-known example at the moment is PipeWire. The PipeWire (and WirePlumber) packages ship with service and socket unit files for use with systemd in "per-user service manager" mode. Meaning that the corresponding daemons run with effective user equal to some login user. The service unit files have Type=simple and Restart=on-failure directives, so, using s6-rc terminology, the daemons are effectively treated the same as 'system' longruns for the duration of a login session. The files also have dependency specification directives, so both packages expect actual service manager functionality for taking care of the daemons. * https://gitlab.freedesktop.org/pipewire/pipewire/-/tree/1.6.0/src/daemon/systemd/user?ref_type=tags * https://gitlab.freedesktop.org/pipewire/wireplumber/-/tree/0.5.13/src/systemd/user?ref_type=tags On systemd-based operating systems, login sessions are tracked by a 'system' longrun, systemd-logind. There's also a PAM module, pam_systemd, that notifies systemd-logind (via D-Bus) in its pam_sm_open_session() function that a login session for a user has started, and asks it to do all additional session startup work, and notifies systemd-logind in its pam_sm_close_session() function that a login session for a user has ended, and asks it to do all additional session teardown work. Future versions of GNOME look like they are also going to start relying on similar functionality:. * https://blogs.gnome.org/adrianvovk/2025/06/10/gnome-systemd-dependencies ----- What Gentoo with OpenRC has traditionally done for dealing with PipeWire and WirePlumber, is installing a script that tries to emulate the behaviour, and that is called by desktop environments that implement Freedesktop's desktop application autostart specification. * https://gitweb.gentoo.org/repo/gentoo.git/tree/media-video/pipewire/files/gentoo-pipewire-launcher.in-r4?id=20c3561947c263ea300c9e04a134910539f9c191 * https://specifications.freedesktop.org/autostart/0.5 But, with navi-desu's contributions, OpenRC added user services in version 0.60, so Gentoo now also ships corresponding OpenRC user service scripts. ----- OpenRC's implementation of user services adds a new --user option for the openrc program, and a different set of directories for its various purposes when --user is passed (/etc/user/init.d and $XDG_CONFIG_HOME/rc/init.d instead of /etc/init.d, $XDG_CONFIG_HOME/rc/runlevels instead of /etc/runlevels, etc.). The tie with login sessions is a PAM module, pam_openrc, and some helpers: the openrc-user program, system service /etc/init.d/user and 'glue' shell script ${libexecdir}/rc/sh/openrc-user.sh. pam_openrc's pam_sm_open_session() and pam_sm_close_session() functions start and stop, respectively, an instance of service "user" for the appropriate login user. Which runs openrc-user. Which (indirectly) runs 'openrc --user' with suitable arguments on startup and termination. ----- I didn't think too deeply about it, but, In its current state, I looks to me like s6 and s6-rc could be used as well for packages that expect this systemd-like user services functionality: * s6-rc longruns are supervised by s6, so daemons that fit the Type=simple and Restart=on-failure model should work well with them. * s6-rc is a proper service manager, so it should be capable of managing user services. s6-rc programs work on a live state directory linked to a compiled service database, and nothing prevents having a 'system' live state directory at /run/s6-rc, and additional per-user live state directories. The -l option can be used for specifying operations on one particular user's services. * s6-instance-create and s6-instance-delete look like they could provide the "start all user services" and "stop all user services" functionality, with a template that probably would look quite close to the output of s6-usertree-maker. What is missing is the tie with login sessions, which would probably require dealing with those "unsavory interfaces". That's why I was interested in what Alexis was doing. If *I* had to go look for a quick solution, I would probably borrow pam_openrc from OpenRC and look into adapting it for calling s6-instance-create, s6-instance-delete, 's6-rc-init -l $user_livedir', 's6-rc -l $user_livedir start $default_bundle', 's6-rc -l $user_livedir -da change', etc. instead. G.
