s6/s6-rc policy for Gentoo

s6/s6-rc policy for Gentoo

[Paul Sopka]

[-- Attachment #1.1.1: Type: text/plain, Size: 1805 bytes --]

Hey everybody

I am currently working on implementing boot scripts, system services, 
user services and general policy for Gentoo with s6/s6-rc.

I will soon (once I consider it acceptable) publish a github repo of my 
current state, so others can criticize, improve and suggest components. 
The plans is to, after some fleshing out, open another repo containing 
an overlay with a profile and some packages, so it can be easily 
installed for testing purposes. In the best case this shall once be 
merged into official Gentoo.


Currently I see two major things I still need to solve:

1) A service monitoring logged in users, starting the user supervision 
tree on the first login of a user and stopping it once the user logs out 
from the last shell/display manager

2) An elegant way of synchronizing environment variables between the 
users supervision tree and its services and the users login 
shell/compositor/...


Regarding 1) the best idea I currently is to have a daemon monitoring 
/var/run/utmp, starting an sub-process/s6-rc service for each user 
appearing there and stopping this sub-process/s6-rc service once the 
last login instance of the user vanished from that file. Since I have 
very little programming experience, I wanted to as you, Bercot, whether 
you consider this a good idea and if you do, whether this would be worth 
a s6 program. Can this be achieved in a better way?

Regarding 2) I do not currently have an idea.

Apart from those, there is still a lot to do, e.g. writing basic service 
scripts, and improving and expanding the boot scripts.

Of course, I will notify this list once the repo is up.

Any suggestions and ideas are welcome, even if they do not belong to 1) 
or 2)!


I wish you all a nice weekend!

Paul


[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3195 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: s6/s6-rc policy for Gentoo

[Mobin Aydinfar]

On ۱۴۰۳/۴/۱۵ ۱۷:۳۹, Paul Sopka wrote:
> Hey everybody
> 
> I am currently working on implementing boot scripts, system services, 
> user services and general policy for Gentoo with s6/s6-rc.
> 
> I will soon (once I consider it acceptable) publish a github repo of my 
> current state, so others can criticize, improve and suggest components. 
> The plans is to, after some fleshing out, open another repo containing 
> an overlay with a profile and some packages, so it can be easily 
> installed for testing purposes. In the best case this shall once be 
> merged into official Gentoo.
> 


Hi!
That's really nice and I'm really excited about that repo :)

> Currently I see two major things I still need to solve:
> 
> 1) A service monitoring logged in users, starting the user supervision 
> tree on the first login of a user and stopping it once the user logs out 
> from the last shell/display manager


I think "turnstile" is a suitable option for this purpose. It's designed 
in three parts: a PAM module for detecting logins, a Daemon and some 
service supervisor loader scripts (backends). Currently it does support 
Dinit and Runit as backends but there should not be any problem around 
writing a backend for s6-rc. See 
https://github.com/chimera-linux/turnstile for project itself and more info.

Best Regards

Re: s6/s6-rc policy for Gentoo

[Paul Sopka]

[-- Attachment #1.1.1: Type: text/plain, Size: 729 bytes --]

> I think "turnstile" is a suitable option for this purpose. It's 
> designed in three parts: a PAM module for detecting logins, a Daemon 
> and some service supervisor loader scripts (backends). Currently it 
> does support Dinit and Runit as backends but there should not be any 
> problem around writing a backend for s6-rc. See 
> https://github.com/chimera-linux/turnstile for project itself and more 
> info. 
Thank you for your suggestion, this looks very promising. I will read 
into pam and write a local ebuild to install and test turnstile. This 
ebuild shall then be part of the overlay.

Anyhow, it seems this is the best solution until Bercot comes up with an 
alternative to PAM and utmp.


Paul


[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3195 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: s6/s6-rc policy for Gentoo

[Laurent Bercot]

>1) A service monitoring logged in users, starting the user supervision tree on the first login of a user and stopping it once the user logs out from the last shell/display manager

  Ah, user services. They're a complicated matter, and their exact
definition varies depending on the distro. They're very much tied to
distro policies, which is why I haven't written support for them in s6,
apart from s6-usertree-maker that may or may not be useful to you.

  When you say "user services", it generally means one of these things:

  A. a permanent supervision tree, belonging to a normal user, that runs
services as the user, independent from whether the user is logged in.
  B. A supervision tree that starts with the first login and ends with
the last logout. This appears to be what you're working on.
  C. A supervision tree that is tied to a graphical session on one seat.
That would exclude remote logins via ssh. This seems to be what the
Freedesktop people have in mind when they talk about XDG specifications.

  You're not the only one working on s6-rc user services for Gentoo: see
https://skarnet.org/lists/supervision/3074.html :) You should definitely
try and coordinate with Alexis! And also with other people who hang
on the #s6 channel on oftc.net and may have more ideas to share.


>2) An elegant way of synchronizing environment variables between the users supervision tree and its services and the users login shell/compositor/...

  Generally speaking, when I have a set of environment variables that
need to be shared between unrelated sets of processes, I put them in
an envdir, and source the envdir whenever the variables are needed.
One way or the other, the only reliable data sharing tool you have
across process trees is the filesystem.


>Regarding 1) the best idea I currently is to have a daemon monitoring /var/run/utmp, starting an sub-process/s6-rc service for each user appearing there and stopping this sub-process/s6-rc service once the last login instance of the user vanished from that file. Since I have very little programming experience, I wanted to as you, Bercot, whether you consider this a good idea and if you do, whether this would be worth a s6 program. Can this be achieved in a better way?

  Since you're going with option B, indeed you'll need something to
detect logins, but relying on utmp is a risky business, and you don't
want to interface with PAM yourself. Having a third-party program
dedicated to that is probably the right approach; Mobin mentioned
turnstile, this looks like a promising option.

  I'm not going to write such a program in the s6 suite, because all the
stuff around PAM and utmp is 1. very Linux-specific and 2. extremely
brittle and badly/underspecified. At some point, however, I intend to
take a good look at PAM and brainstorm about a replacement, because the
current situation is just holding with massive amounts of duct tape, 
good
will and headaches, and this makes me fearful for the future.

  In any case, be wary of the trap of using XDG_RUNTIME_DIR to host your
user supervision tree. It *looks* like the ideal place to do so, but
in case of a desktop session, it's deleted too early and you don't
have time to properly terminate your services. Other people who have
experience with running user services on a desktop will talk about this
better than me.

--
  Laurent

Re: s6/s6-rc policy for Gentoo

[Paul Sopka]

[-- Attachment #1.1.1: Type: text/plain, Size: 5199 bytes --]

Hey, thank you for your detailed answer!

>  A. a permanent supervision tree, belonging to a normal user, that runs
> services as the user, independent from whether the user is logged in. 
Wouldn't anything this does be solved by just dropping privileges of the 
corresponding daemons in their startup scripts? That would mean that it 
is just a needless complication. Anyway, this is the workaround I am 
using on my machine right now xD.


>  B. A supervision tree that starts with the first login and ends with
> the last logout. This appears to be what you're working on. 
Yes.


>  C. A supervision tree that is tied to a graphical session on one seat.
> That would exclude remote logins via ssh. This seems to be what the
> Freedesktop people have in mind when they talk about XDG specifications. 
This seems like a worse and less flexible version of B to me, I guess 
the only reason it is even considered is because the seat daemon does 
all the tracking work for you. Option B does all this does and more if I 
understand you correctly, thus I think B is straight up the better way.

One might now argue that some processes need e.g. a running wayland 
compositor, but this is the exact case "socket activation" solves. Let's 
take for example the "foot" terminal 
emulator(https://codeberg.org/dnkl/foot), which can be run as a server 
to accept "footclient" terminal emulator instances, saving memory and 
startup time. The server can only be startet once a wayland compositor 
is up and running. Using "socket activation"(fd-holding) it can be 
configured to only be started once the first instance of "footclient" is 
invoked, which can only happen once the compositor is up thus solving 
this issue completely. This should be applicable to most if not all 
software with this limitation.

Does anyone see any other problem arising from B?


>  You're not the only one working on s6-rc user services for Gentoo: see
> https://skarnet.org/lists/supervision/3074.html :) You should definitely
> try and coordinate with Alexis! And also with other people who hang
> on the #s6 channel on oftc.net and may have more ideas to share. 
Thanks for the intel!


>  Generally speaking, when I have a set of environment variables that
> need to be shared between unrelated sets of processes, I put them in
> an envdir, and source the envdir whenever the variables are needed.
> One way or the other, the only reliable data sharing tool you have
> across process trees is the filesystem. 
I thought about this, too. And I see two issues to solve:

A) The format, do you suggest a FILENAME=content which seems easier to 
handle with execline and other software's(e.g. dbus) ability to write 
specific info to an fd which can be redirected to a file? Or do you 
think a file containing KEY=value, probably playing more nicely with 
bash and other interactive shells?

B) I think I need to make an example to explain this issue properly:

I use Hyprland(https://hyprland.org/), which I start from an agetty 
instance. Hyprland, as any other wayland compositor/DE, sets env's. Most 
importantly WAYLAND_DISPLAY. It does not write those to a file. Thus I 
would require the user to add a script launch command to Hyprland's 
config which launches a script exporting the required(or all?) env's to 
a dir. This is unacceptable.

Plan b) Poll the user env and extract on change and write it to the env 
dir, but how to extract the env? Polling is bad.

Plan c) use a notification by a seat manager(e.g. seatd) to run a script 
that extracts the env and writes it to the env dir, again, how to 
extract the env? This is also bad, since this will most likely end up 
being seatd specific, or at least bound to a set of supported seat managers.

Does anybody have a better idea?


>  I'm not going to write such a program in the s6 suite, because all the
> stuff around PAM and utmp is 1. very Linux-specific and 2. extremely
> brittle and badly/underspecified. At some point, however, I intend to
> take a good look at PAM and brainstorm about a replacement, because the
> current situation is just holding with massive amounts of duct tape, good
> will and headaches, and this makes me fearful for the future. 
Thank you for the info, I have the greatest respect for you writing only 
UNIX compatible software(if that's how to correctly describe it?). I am 
looking forward to your alternative to PAM.


>  In any case, be wary of the trap of using XDG_RUNTIME_DIR to host your
> user supervision tree. It *looks* like the ideal place to do so, but
> in case of a desktop session, it's deleted too early and you don't
> have time to properly terminate your services. Other people who have
> experience with running user services on a desktop will talk about this
> better than me. 
I will open a separate thread on the XDG Base Directory Specification, 
since I consider this an important point. Generally I'd like to use 
XDG_RUNTIME_DIR but have it managed by the the s6-rc system service 
providing the user service tree. Thus it should be safe.

Any objections to the second point?


Paul


[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3195 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: s6/s6-rc policy for Gentoo

[Laurent Bercot]

>Wouldn't anything this does be solved by just dropping privileges of the corresponding daemons in their startup scripts?

  No, because the point is to allow users to have their own services,
and you definitely don't want them to have access to the root
supervision tree. So you basically have to have a separate subtree
for each user (a privilege-dropped s6-svscan), and there are a few more
policy questions to answer, in particular how to make sure the users
cannot flood the root logs by misconfiguring their own logging system.
It's doable, but not quite obvious, and it's also not quite obvious
how to set up the system so that you don't spawn a supervision tree for
inactive users or users who don't use the feature. So there's a little
more work involved.


>This seems like a worse and less flexible version of B to me, I guess the only reason it is even considered is because the seat daemon does all the tracking work for you. Option B does all this does and more if I understand you correctly, thus I think B is straight up the better way.

  It really depends on your objective. B makes a lot of sense if you
want to treat remote logins the same way as seated logins, but there is
also an argument to have remote logins be as simple as possible while
not minding deploying the red carpet and a whole lot of extra services
for seated logins, where the overhead of setting everything up will be
negligible compared to the desktop stuff anyway.


>Does anyone see any other problem arising from B?

  B is entirely legit if you make it clear that's what users get. Just to
make sure users don't run xeyes when logging in remotely.
  And you probably want an extra supervision tree just for seated stuff
anyway, see below.


>A) The format, do you suggest a FILENAME=content which seems easier to handle with execline and other software's(e.g. dbus) ability to write specific info to an fd which can be redirected to a file? Or do you think a file containing KEY=value, probably playing more nicely with bash and other interactive shells?

  The format doesn't matter if you control the readers. s6-envdir reads
envdirs, envfile reads key=value shell-like files. Choose whatever
format works best for you; if you need the variables to be read from a
shell as well, the envfile format will work best. It's a question of
convenience and preference, really.


>B) I think I need to make an example to explain this issue properly:
>
>I use Hyprland(https://hyprland.org/), which I start from an agetty instance. Hyprland, as any other wayland compositor/DE, sets env's. Most importantly WAYLAND_DISPLAY. It does not write those to a file. Thus I would require the user to add a script launch command to Hyprland's config which launches a script exporting the required(or all?) env's to a dir. This is unacceptable.

  That means WAYLAND_DISPLAY, by design, is only be accessible to
processes that descend from Hyprland. Why do you need to subvert it so
unrelated processes can access it?
  When Hyprland isn't running, there shouldn't be any living processes
relying on WAYLAND_DISPLAY. That suggests that you want a separate
supervision tree, launched under Hyprland, to host processes that only
make sense for a seated login - just like the C case above.

  I don't think that any hack to get the value of WAYLAND_DISPLAY and
store it for access by unrelated processes makes sense. Supervision
trees are cool, but they shouldn't be used to bypass normal process
hierarchies. Write down exactly what your services' lifetime should be
and design accordingly.


>Thank you for the info, I have the greatest respect for you writing only UNIX compatible software(if that's how to correctly describe it?). I am looking forward to your alternative to PAM.

  Don't hold your breath - this is a longterm plan, and a considerable
amount of work.

--
  Laurent

Re: s6/s6-rc policy for Gentoo

[Paul Sopka]

[-- Attachment #1.1.1: Type: text/plain, Size: 8395 bytes --]

>  No, because the point is to allow users to have their own services,
> and you definitely don't want them to have access to the root
> supervision tree. So you basically have to have a separate subtree
> for each user (a privilege-dropped s6-svscan), and there are a few more
> policy questions to answer, in particular how to make sure the users
> cannot flood the root logs by misconfiguring their own logging system.
> It's doable, but not quite obvious, and it's also not quite obvious
> how to set up the system so that you don't spawn a supervision tree for
> inactive users or users who don't use the feature. So there's a little
> more work involved. 
I know what you mean, and technically and in theory I fully agree with 
you. As mentioned this is my currently running workaround until I 
implement Turnstile.

My claim was more about a practical, applied scenario. In the terms of: 
If a user is not logged in, he simply cannot control his services. So 
why shall he have an entire user supervision tree of which the sole 
purpose is to allow the user to control the services running with his 
permission set, running at a time he is not logged in, thus not able to 
control his services?

I am sure there are niche cases this solves, but I do not think they are 
worth the overhead/maintenance burden of adding this on top of B).

Do you see any cases where this would actually be useful in real world 
applications?

> in particular how to make sure the users
> cannot flood the root logs by misconfiguring their own logging system.
I solved that by simple read/write permissions on on the root log dir, 
if you mean that.

If you are talking about flooding the uncaught logs logger of the 
system. Is this not just solved by a s6-log service attached to the user 
s6-svscan, acting as a catch all logger for the user tree. Since this is 
inherently a system service, the user does not have the power to 
sabotage this.

I am not sure whether I got you right on that.

Concerning your last point, the best I can offer for now is to have a 
script, using a template dir to create the user supervision system 
service. This can of course only be done by the system admin. The user 
can then add whatever he wants to a previously empty bundle described in 
the wiki, before invoking an "s6-user-db-update" command or similar, 
invoking a script that I supply and that does the compilation and 
s6-rc-update command.

B) shall solve the issue of not spawning needless supervision trees, 
since it only spawns them upon login.


>  It really depends on your objective. B makes a lot of sense if you
> want to treat remote logins the same way as seated logins, but there is
> also an argument to have remote logins be as simple as possible while
> not minding deploying the red carpet and a whole lot of extra services
> for seated logins, where the overhead of setting everything up will be
> negligible compared to the desktop stuff anyway.
I, again, technically agree fully, but this is in my opinion already 
solving itself in practice: on a desktop system you rarely have someone 
ssh'ing in. On a server system no user will ever add heavy desktop 
scripts to the user service autostart, because a) he can't use them 
anyway and b) they shouldn't be there(why the heck should the sysadmin 
install e.g. pipewire or mpd on such a server? Packages which would be 
responsible for drawing in the required user services.)

If you are actually talking about setting up s6-svscan etc., I think 
that a) your software and solutions resource consumption is negligible 
on modern hardware, b) I would consider user services to be a more 
desktop centric system anyway.


>  B is entirely legit if you make it clear that's what users get. Just to
> make sure users don't run xeyes when logging in remotely. 
lmao


>  The format doesn't matter if you control the readers. s6-envdir reads
> envdirs, envfile reads key=value shell-like files. Choose whatever
> format works best for you; if you need the variables to be read from a
> shell as well, the envfile format will work best. It's a question of
> convenience and preference, really. 

This is why I am asking all the (more experienced) people on this list. 
So that I make the best and most informed decision.

Since the only purpose is to synchronize interactive shells like 
bash/zsh/..., this is probably the deciding point:

> if you need the variables to be read from a
> shell as well, the envfile format will work best.

>  That means WAYLAND_DISPLAY, by design, is only be accessible to
> processes that descend from Hyprland. Why do you need to subvert it so
> unrelated processes can access it? 
  Apologies, I did not explain that well. It basically goes hand in hand 
with what I have written here:

> One might now argue that some processes need e.g. a running wayland
> compositor, but this is the exact case "socket activation" solves. Let's
> take for example the "foot" terminal
> emulator(https://codeberg.org/dnkl/foot), which can be run as a server
> to accept "footclient" terminal emulator instances, saving memory and
> startup time. The server can only be startet once a wayland compositor
> is up and running. Using "socket activation"(fd-holding) it can be
> configured to only be started once the first instance of "footclient" is
> invoked, which can only happen once the compositor is up thus solving
> this issue completely. This should be applicable to most if not all
> software with this limitation.

And by "up and running" I mean WAYLAND_DISPLAY is set by the compositor.

I would not call the foot terminal emulator unrelated to WAYLAND_DISPLAY 
and the compositor at all.

But I argue that, in case it is ran in it's server configuration, it 
makes sense to supervise it, i.e. not starting it directly from the 
compositor. The same can be said about notification daemons, status 
bars, ...

As you have already said this is the best example for why an additional 
C) would make sense. This is where my next problem arises, imagine we 
now set up another supervision tree for starting it up as soon as the 
compositor is there.

I can probably cleanly do this my reading from the socket seatd provides 
and using s6-fdholder-retrieve, right? How could this be stopped cleanly 
upon exiting the wayland compositor?

The issue on how to retrieve WAYLAND_DISPLAY arises again.

This could be solved by starting the "graphical" s6-svscan from the 
compositor, e.g. Hyprland, even though the compositor is not supervised, 
once it crashes it takes everything depending on it down with it anyway, 
so this doesn't matter. The biggest issue is, yet again, how to stop the 
services cleanly on exiting the compositor. Any ideas?


Another issue I see is that the user of the desktop system gets a third 
supervision tree he has to manage. And for most of the more casual 
people it is probably hard to correctly understand and use the 
differences between C) and B), in the little free time they can invest 
into linux.

This is why I looked at the idea of "socket activation", but now that I 
think of it, this will probably fail for notification daemons, status 
bars, etc.


Anyhow, you have convinced me, the third supervision is the most elegant 
and clean option. I am yet again thankful for your detailed answer. I 
have learned a lot and you made me aware of issues I did not see, but 
have to solve.


There is another alternative I see: starting the compositor itself as a 
user service. I have to think about how feasible this is. What do you think?

This brings me to the final problem which the alternative mentioned 
above solves already: The user services manage a couple of things, 
namely the XDG_RUNTIME_DIR and DBUS_SESSION_BUS_ADDRESS that need to be 
propagated to the users login shell. Is there a more elegant way to do 
this other then having the user source an env directory in his 
.bash_profile?


>  Don't hold your breath - this is a longterm plan, and a considerable
> amount of work. 
I will not :D. I will settle with Turnstile for now (testing it today 
evening), but I will happily replace it once your future solution is 
finished. Your software appears perfect to me.

Thank you!

Paul


[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3195 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: s6/s6-rc policy for Gentoo

[Hoël Bézier]

[-- Attachment #1.1: Type: text/plain, Size: 921 bytes --]

Hi,

Am Sa, Jul 06, 2024 am 03:09:26 +0200 schrieb Paul Sopka:
>This brings me to the final problem which the alternative mentioned
>above solves already: The user services manage a couple of things,
>namely the XDG_RUNTIME_DIR and DBUS_SESSION_BUS_ADDRESS that need to be
>propagated to the users login shell. Is there a more elegant way to do
>this other then having the user source an env directory in his
>.bash_profile?

What I do is little different: my login shell is /etc/execline-startup, which 
after setting up a few things, execs into ~/.execline-loginshell, which among 
other things execs into s6-envdir reading the same env dir as my supervision 
tree, and finally executes into my actual shell.

I’ll attach the files to this email so you can take a look at them.

Don’t credit me on this, I actually took it all from the lh-bootstrap stuff 
written by Laurent. :D

BISOUS
Hoël

[-- Attachment #1.2: execline-startup --]
[-- Type: text/plain, Size: 279 bytes --]

#!/bin/execlineb -s0

/bin/multisubstitute
{
  importas -i HOME HOME
  importas -i LOGNAME LOGNAME
}
/bin/export USER ${LOGNAME}
/bin/s6-envdir /etc/env-startup
/bin/fdblock 0
/bin/fdblock 1
/bin/fdblock 2

/bin/tryexec { ${HOME}/.execline-loginshell $@ }
/etc/execline-shell $@

[-- Attachment #1.3: .execline-loginshell --]
[-- Type: text/plain, Size: 161 bytes --]

#!/bin/execlineb -s0
importas -i PATH PATH
importas -i HOME HOME
export PATH ${HOME}/.local/bin:${PATH}
s6-envdir ${HOME}/.config/env
${HOME}/.execline-shell $@

[-- Attachment #1.4: .execline-shell --]
[-- Type: text/plain, Size: 58 bytes --]

#!/bin/execlineb -s0
backtick -nx GPG_TTY { tty }
fish $@

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: s6/s6-rc policy for Gentoo

[Paul Sopka]

[-- Attachment #1.1.1: Type: text/plain, Size: 811 bytes --]

> What I do is little different: my login shell is 
> /etc/execline-startup, which after setting up a few things, execs into 
> ~/.execline-loginshell, which among other things execs into s6-envdir 
> reading the same env dir as my supervision tree, and finally executes 
> into my actual shell.
>
> I’ll attach the files to this email so you can take a look at them.

This looks sensible, I might use this for myself.

That said, I have come to the following conclusion: Gentoo is a 
distribution based on choice and freedom of configuration. Thus I will 
probably just add a section to the user-service wiki entry I will write, 
explaining what directory has to be sourced and why as well as providing 
examples on how to do this with the most common login methods.

Thank you!


Paul


[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3195 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: s6/s6-rc policy for Gentoo

[Jan Braun]

[-- Attachment #1: Type: text/plain, Size: 5386 bytes --]

Paul Sopka schrob:
> My claim was more about a practical, applied scenario. In the terms of: If a
> user is not logged in, he simply cannot control his services. So why shall
> he have an entire user supervision tree of which the sole purpose is to
> allow the user to control the services running with his permission set,
> running at a time he is not logged in, thus not able to control his
> services?

That part seems confused. The user is able to control their services by
logging in and then invoking s6-whatever.

> Do you see any cases where this would actually be useful in real world
> applications?

Replacing crond with snooze, for example.
And personally, I want my ssh-agent to stay alive when I log out, so
that the key is still unlocked if/when I immediately log in again.

> Concerning your last point, the best I can offer for now is to have a
> script, using a template dir to create the user supervision system service.
> This can of course only be done by the system admin. The user can then add
> whatever he wants to a previously empty bundle described in the wiki, before
> invoking an "s6-user-db-update" command or similar, invoking a script that I
> supply and that does the compilation and s6-rc-update command.

This sounds unnecessarily complicated. Why not simply test for existence
of a well-known entry point somewhere in $HOME and let that set up the
user supervision tree however it sees fit (or not at all)?

> on a desktop system you rarely have someone ssh'ing in.
> On a server system no user will ever add heavy desktop scripts to the user
> service autostart, because a) he can't use them anyway and b) they shouldn't
> be there(why the heck should the sysadmin install e.g. pipewire or mpd on
> such a server? Packages which would be responsible for drawing in the
> required user services.)

Ugh. I hate this thinking. Server/Desktop is not a binary choice. I
regularly ssh into otheruser@localhost on my main machine. Sometimes I
log in as otheruser and startx. Occasionally I start a vnc server as
otheruser. I have an mpd instance that runs as its own user.

Any desktop-only solution where people argue "you shouldn't do this on a
server" is one where I'll argue "you shouldn't do this at all".

> [...]
> And by "up and running" I mean WAYLAND_DISPLAY is set by the compositor.
> 
> I would not call the foot terminal emulator unrelated to WAYLAND_DISPLAY and
> the compositor at all.
> 
> But I argue that, in case it is ran in it's server configuration, it makes
> sense to supervise it, i.e. not starting it directly from the compositor.
> The same can be said about notification daemons, status bars, ...

You can supervise it, but the supervision tree is dependent on the
compositor. If the compositor goes away, the supervision tree needs to
die as well. If you start two compositors, you need to create two
supervision trees, one for each WAYLAND_DISPLAY.

> As you have already said this is the best example for why an additional C)
> would make sense. This is where my next problem arises, imagine we now set
> up another supervision tree for starting it up as soon as the compositor is
> there.
> 
> I can probably cleanly do this my reading from the socket seatd provides and
> using s6-fdholder-retrieve, right? How could this be stopped cleanly upon
> exiting the wayland compositor?
> 
> The issue on how to retrieve WAYLAND_DISPLAY arises again.
> 
> This could be solved by starting the "graphical" s6-svscan from the
> compositor, e.g. Hyprland, even though the compositor is not supervised,
> once it crashes it takes everything depending on it down with it anyway, so
> this doesn't matter. The biggest issue is, yet again, how to stop the
> services cleanly on exiting the compositor. Any ideas?

* create a unique live dir from the "graphical" template
* start compositor
** in compositor's autostart, have something that exports the
   WAYLAND_DISPLAY and calls s6-rc start
** (if possible) register s6-rc stop as an exit hook with compositor
* once the compositor exits, tear down everything.

Or just use X11, which properly separates Xserver from WM, avoiding any
problems caused by uncooperative compositors. <scnr>

> Another issue I see is that the user of the desktop system gets a third
> supervision tree he has to manage. And for most of the more casual people it
> is probably hard to correctly understand and use the differences between C)
> and B), in the little free time they can invest into linux.

If it needs a display, it goes into C, otherwise into B.

> There is another alternative I see: starting the compositor itself as a user
> service. I have to think about how feasible this is. What do you think?

Feasible, sure. Good idea, probably not. A misconfigured compositor
restarting over and over again is a pain to fix.

> This brings me to the final problem which the alternative mentioned above
> solves already: The user services manage a couple of things, namely the
> XDG_RUNTIME_DIR and DBUS_SESSION_BUS_ADDRESS that need to be propagated to
> the users login shell. Is there a more elegant way to do this other then
> having the user source an env directory in his .bash_profile?

PAM. Assuming you use PAM to create the XDG_RUNTIME_DIR and start the
dbus.

regards,
    Jan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: s6/s6-rc policy for Gentoo

[Paul Sopka]

[-- Attachment #1.1.1: Type: text/plain, Size: 3587 bytes --]

> Replacing crond with snooze, for example.
> And personally, I want my ssh-agent to stay alive when I log out, so
> that the key is still unlocked if/when I immediately log in again.

You have convinced me, I will see whether it is feasible to have a 
*third* user-service tree. I fear I just have to bite the bullet and 
decide upon one or two options or at least let the sysadmin decide. Yet 
another reason to not integrate extremely tight into Turnstile and 
similar, which would disallow this flexibility.

An alternative would be two main bundles per user service tree, that 
itself always starts on boot:

One to start at boot time.

Another one to start on first login and stop on last login.

This seems the most elegant and efficient. Am I overlooking anything?


> This sounds unnecessarily complicated. Why not simply test for existence
> of a well-known entry point somewhere in $HOME and let that set up the
> user supervision tree however it sees fit (or not at all)?

If I understand correctly, this would only be possible using 
instantiated services, I like the idea and I am looking into this.


> Ugh. I hate this thinking. Server/Desktop is not a binary choice. I
> regularly ssh into otheruser@localhost on my main machine. Sometimes I
> log in as otheruser and startx. Occasionally I start a vnc server as
> otheruser. I have an mpd instance that runs as its own user.
>
> Any desktop-only solution where people argue "you shouldn't do this on a
> server" is one where I'll argue "you shouldn't do this at all".

It looks like I just do not have enough experience, that's why I am 
asking you all on those points. You are right.

Using the idea I stated above, one could use different PAM modules to 
start different bundles tho, e.g. an ssh bundle on ssh login, a getty 
bundle on getty login, a greetd bundle on greetd login.


> * create a unique live dir from the "graphical" template
> * start compositor
> ** in compositor's autostart, have something that exports the
>     WAYLAND_DISPLAY and calls s6-rc start
> ** (if possible) register s6-rc stop as an exit hook with compositor
> * once the compositor exits, tear down everything.

Yes, I have suggested this too, the issues is not the starting part, but 
the proper stopping of the services. This can only be guaranteed if the 
compositor sends SIGTERM to s6-svscan upon exiting. I still need to test 
that, but to not have to rely on the compositor doing that correctly is 
why I have proposed hooking into seatd in the first place.

The finish script of the s6-svscan should then handle cleanup just fine.

> Or just use X11, which properly separates Xserver from WM, avoiding any
> problems caused by uncooperative compositors. <scnr>

I am planning to support an entire distro, thus I need to support them 
all: well behaved compositors, badly behaved compositors, X11, ...


> If it needs a display, it goes into C, otherwise into B.
I guess writing this into a wiki article mandatory for user services 
anyway would be good enough.


> Feasible, sure. Good idea, probably not. A misconfigured compositor
> restarting over and over again is a pain to fix.
Agreed.


> PAM. Assuming you use PAM to create the XDG_RUNTIME_DIR and start the
> dbus.
Using PAM for propagating the env's seems reasonable, since we are using 
it already anyway. Will test.

On a sidenote, I still think creating XDG_RUNTIME_DIR should be the job 
of the system-service managing the user tree.


Thank you for your input!


Paul


[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3195 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: s6/s6-rc policy for Gentoo

[Jan Braun]

[-- Attachment #1: Type: text/plain, Size: 2147 bytes --]

Paul Sopka schrob:
> An alternative would be two main bundles per user service tree, that itself
> always starts on boot:
> 
> One to start at boot time.
> Another one to start on first login and stop on last login.
> This seems the most elegant and efficient. Am I overlooking anything?

I am not too familiar with s6 bundles (I use runit, not s6), but that
sounds reasonable.

> > This sounds unnecessarily complicated. Why not simply test for existence
> > of a well-known entry point somewhere in $HOME and let that set up the
> > user supervision tree however it sees fit (or not at all)?
> 
> If I understand correctly, this would only be possible using instantiated
> services, I like the idea and I am looking into this.

Not sure what you mean by "instantiated services". But see below.

> > Ugh. I hate this thinking. [...]
> 
> It looks like I just do not have enough experience, that's why I am asking
> you all on those points. You are right.

Sorry for my tone, I realize I was grumpy, possibly offensively so. You
took it well, thanks. :)

> Using the idea I stated above, one could use different PAM modules to start
> different bundles tho, e.g. an ssh bundle on ssh login, a getty bundle on
> getty login, a greetd bundle on greetd login.

While I don't know why one would want to differentiate between those,
you probably can do that quite straightforwardly with pam_exec(8)
calling a tiny script that tracks the number of active sessions (of type
"$1") and calls s6-rc on zeroes.


And if you want to make this machinery user-customizable, you'll need
three user entry points:
~/.foo/supervisor
    defaulting to "s6-svscan $scandir"
~/.foo/login <type> <concurrent>
    defaulting to "if $concurrent == 0 then s6-rc start $type"
~/.foo/logout <type> <concurrent>
    defaulting to "if $concurrent == 0 then s6-rc stop $type"

And you'll need one admin action which creates the service supervising
~$USER/.foo/supervisor (if that service doesn't exist yet). To be
triggered on user account creation, or probably on login if things like
ldap are involved.

regards,
    Jan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: s6/s6-rc policy for Gentoo

[Paul Sopka]

[-- Attachment #1.1.1.1: Type: text/plain, Size: 1854 bytes --]

> Not sure what you mean by "instantiated services". But see below.
See here: https://skarnet.org/software/s6/instances.html.


> Sorry for my tone, I realize I was grumpy, possibly offensively so. You
> took it well, thanks. 🙂

No worries, in my opinion the focus should be on being more resilient 
and less careful when talking anyway. I think that allows for more 
direct and efficient communication.

Also, you were right.


> While I don't know why one would want to differentiate between those,
> you probably can do that quite straightforwardly with pam_exec(8)
Many probably do not need pipewire, mpd or even dbus started when just 
ssh'ing into a system.

Also see Bercot's comment here: 
https://skarnet.org/lists/supervision/3121.html (paragraph 2).


> And you'll need one admin action which creates the service supervising
> ~$USER/.foo/supervisor (if that service doesn't exist yet). To be
> triggered on user account creation, or probably on login if things like
> ldap are involved.
If I get it right, this is what the instantiated services are supposed 
to resolve automagically.

All that's left is the requirement of the user configuring hist 
autostarts, and if he doesn't, nothing will be instantiated and no 
overhead is generated.

> calling a tiny script that tracks the number of active sessions (of type
> "$1") and calls s6-rc on zeroes.
>
>
> And if you want to make this machinery user-customizable, you'll need
> three user entry points:
> ~/.foo/supervisor
>      defaulting to "s6-svscan $scandir"
> ~/.foo/login <type> <concurrent>
>      defaulting to "if $concurrent == 0 then s6-rc start $type"
> ~/.foo/logout <type> <concurrent>
>      defaulting to "if $concurrent == 0 then s6-rc stop $type"
Amazing, thank you, I will look into that as soon as I can!


Paul


[-- Attachment #1.1.1.2: Type: text/html, Size: 3098 bytes --]

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3195 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: s6/s6-rc policy for Gentoo

[Paul Sopka]

[-- Attachment #1.1.1: Type: text/plain, Size: 4807 bytes --]

Thanks for your input!

> As Mobin said, Turnstile from Chimera Linux answers this problem, and 
> also manages the XDG_RUNTIME_DIR folder.
> Since it actually has hooks to coordinate with the supervisor (unlike 
> elogind, where the systemd-specific code for that in logind is just 
> stubbed out), it makes XDG_RUNTIME_DIR safe to use. All that's needed 
> is a s6-rc-aware backend. I'd write one, but haven't yet because I 
> already have user services set up using Laurent's approach A (i.e. a 
> user service tree that's always up regardless of login) and the fact 
> that s6-rc uses a compiled database introduces some questions existing 
> backends have no answer for (Should the the database be compiled upon 
> login? Should the backend come with a wrapper around s6-rc-compile 
> aware of turnstile's settings? etc.).

I am looking at Turnstile, it indeed appears to be the right tool for 
the job, until Bercot develops an alternative to PAM.

> Since it actually has hooks to coordinate with the supervisor (unlike 
> elogind, where the systemd-specific code for that in logind is just 
> stubbed out), it makes XDG_RUNTIME_DIR safe to use.

I am planning to manage XDG_RUNTIME_DIR with s6-rc, since I am planning 
to have it hold the livedir. Even though Turnstile is looking like a 
safe option here, I want to delegate as few critical operation as 
possible to external tools, so I can easily replace e.g. Turnstile with 
a future, improved solution. I am not yet sure whether this is the best 
approach, but up until now it does seem like that. Any critique is welcome!

> All that's needed is a s6-rc-aware backend. I'd write one, but haven't 
> yet because I already have user services set up using Laurent's 
> approach A (i.e. a user service tree that's always up regardless of login)

Regarding A), see my answer here: 
https://skarnet.org/lists/supervision/3116.html. Additionally, I'd like 
to mention that A) is the most efficient and simple solution on a single 
user system, but by no means an elegant one. Also it will will fail on a 
multi-user system, especially considering resource consumption.

I will soon test Turnstile and write a backend. If it works well, it 
will be in the repo and I am looking forward to improvements to it!


> and the fact that s6-rc uses a compiled database introduces some 
> questions existing backends have no answer for (Should the the 
> database be compiled upon login? Should the backend come with a 
> wrapper around s6-rc-compile aware of turnstile's settings? etc.).
I do not think that the backend should be involved in any compilation of 
the db. I see two ways the db/source dir changes:

A) The user adds a custom service / adds any service to autostart

In this case it is also up to the user (with an automation script 
turning it into one command) to compile and update the s6-rc-db.

B) The package manager installs software that includes a script.

In that case it is up to the package manager to invoke the script 
compile and update the s6-rc-db so the user can just start it using the 
usual commands.

A possible alternative would be a system service monitoring all source 
dirs and recompiling on change. This would exchange user control as well 
as resource usage for ease of use, which I generally do not like.


> The approach I use on my machine is prepending the runscripts with 
> `s6-envdir ../../../env` (assuming there's an env folder besides 
> s6-rc's live dir), and touching/writing files there. I don't find this 
> fundamentally inelegant; it follows the general "the filesystem is the 
> database" principle, and avoids introducing an IPC endpoint in the 
> supervisor.
I can't argue with your claim about elegance, I would consider it 
elegant. See https://skarnet.org/lists/supervision/3116.html for the 
issues I see with this.


> Read http://jdebp.uk/Softwares/nosh/avoid-dbus-bus-activation.html if 
> you're writing services for D-Bus stuff (like elogind/bluetoothd).
>
> (Yes, s6-rc isn't well suited for dynamic events yet, so the second 
> approach of replacing the activation program is ugly, but plenty of 
> bug reports in the Artix Linux forum are related to this — I don't 
> know why they haven't disabled it yet).
Thanks for the heads up, will definitely read! To be honest, I did not 
know dbus even had such capabilities and never even considered using 
dbus for such a thing. I rather consider dbus a necessary evil for 
desktop systems. As long as s6-rc does not have dynamic events I will 
simply not try to hack them in. Gentoo users will probably be fine with 
that, since most of them are probably using Open-RC which is way farther 
away from such functionality than s6-rc is.


Paul


[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3195 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]