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.
Received on Sun Mar 01 2026 - 20:56:30 CET