s6-rc as user service manager

s6-rc as user service manager

[Ihor Antonov]

Kicking off another thread because it is slightly different from UX
related questions.

I am trying to get s6-rc set up as a user service manager (similar how
systemd allows user's to manage their own services with systemctl --user
start bla). 
This is useful for example for starting user's dbus, pipewire,
xdg-desktop-portal services, and other stuff that is strictly user
related.

This usecase is geared towards a desktop/laptop.

There are number of challengers that I am facing with this task and I am
not sure how to best solve. I will try to explain those as a set of
scenarios as I amnot yet sure how make it more systematic:

# Scenario 1

It is clear that in the very beginning we have to start svscan on an
empty dir, then run s6-rc-init on it. Lets's assume svscan dir is tmpfs 
and is empty when machine boots. User's shell is configured in
such way that a new login shell spawns s6-svscan on a scan dir and then
runs s6-rc-init. Then necessary services can be started.

User starts their computer,logs in, uses s6-rc to start services
and everything is fine. (or is it?)


# Scenario 2

User logs out their session. Svscan process dies with
the login shell that spawned it. All services supervised by svscan die
too.
If machine is shutting down then we don't care, but it would've been
nice to shut down serices in reverse dependency order.

But machine is not shutting down and user logs in again.
The Scandir is not empty, it contains 
all the links to services that were previously orchestrated with s6-rc.
Login shell spawns svscan process on a scandir and all services start up
immediately, out of order, and therfore some of them fail. Oneshot
service that were intdended to be "once per boot" may run again too.

This is a problem.

# Scenario 3 

A user is logged in on tty1, presses CTRL-ALT-F2 and switches to tty2
and logs in again. A login shell tries to run svscan on a scandir,
svscan fail with error that another process is already running there.
Same happens with s6-rc-init. 

There is s6-svok that tests if a service dir is supervised, but there 
are no similar test tools for scandir and live dir. 
Login shell can ignore errors, but this is bad practice since an error
might happen in other legitimate situation.


# Scenario 4

User has 2 login shells available, tty1 and tty2. User logs out of tty1
and svscan process spawned by tty1 login shell dies, leaving session on
tty2 without neccessary services.



# Problems summary

- Login shell doesn't seem like a good place for user's service manager.
  What is a good place then?

- How to solve "Run service manager once per user"? Such that service
  manager is spawned with the first login and exits correctly with the
  last login?

- Is the amount of login shells a good measure for user's activity? Are
  the other cases when service manager is needed on a desktop machine?
  Like when we have 0 login shells but we need user's service manager?

- Minor: a test utility for svscan dir would be nice
- Minor: a test utility for live dir would be nice
  Checking lock files from shell is not fun and not reliable too

Re: s6-rc as user service manager

[Peter Shkenev]

Hello,

On Mon Oct 17, 2022 at 8:50 PM MSK, Ihor Antonov wrote:
> Kicking off another thread because it is slightly different from UX
> related questions.
>
> I am trying to get s6-rc set up as a user service manager (similar how
> systemd allows user's to manage their own services with systemctl --user
> start bla).
> This is useful for example for starting user's dbus, pipewire,
> xdg-desktop-portal services, and other stuff that is strictly user
> related.
>
> This usecase is geared towards a desktop/laptop.

(There were numerous rants of user services by Laurent Bercot and Colin
Booth on IRC, and I'm going to use those rants as a source).

Firstly, let's try to define "user services" without "bla". There are
three very different options:

1) User services are services running as a given user and started at a
boot time
This option is a trivial one with s6.

2) User services are services defined by users and running supervised
when the user wants it.
You can implement this with s6-usertree-maker [1], which would provide
you with a supervision tree rooted in a system one which can be managed
by user. User will have its own scandir and they can use all commands
provided by s6/s6-rc on their scandir.

3) User services are services that are started when user logs in.
I guess this is what you had in mind when you was typing your letter.
This is the hardest one and badly defined one. There are a lot of
questions:

- What does "user logs in" mean? Do we want services to be
  started when user logs in on the console or at seat? Sshd? Serial
  line?

- When do we stop services? "When the user logs out"? And if the user
  has both an X session and a shell in a console? We need to wait for
  the last connection to drop? How would we get this information? One
  needs some time to shut down the supervision tree.
  One can remember how did systemd killed all user processes on the
  logout.

- Moreover, some services (pipewire, for example) are supposed to be run
  in certain cases, e.g. a graphical session.

- There may be a lot of questions I don't know about.

> - Minor: a test utility for svscan dir would be nice
> - Minor: a test utility for live dir would be nice

If you use s6-rc, those are the same directories, filled by s6-rc-init
and changed by s6-rc-update. So the test would actually test those
utilities, I guess.

[1] https://skarnet.org/software/s6/s6-usertree-maker.html

---
Best regards,
Peter

Re: s6-rc as user service manager

[Ihor Antonov]

On 2022-10-17 23:42, Peter Shkenev wrote:
> ...
> 1) User services are services running as a given user and started at a
> boot time
> This option is a trivial one with s6.
> 
> 2) User services are services defined by users and running supervised
> when the user wants it.
> You can implement this with s6-usertree-maker [1], which would provide
> you with a supervision tree rooted in a system one which can be managed
> by user. User will have its own scandir and they can use all commands
> provided by s6/s6-rc on their scandir.

Thanks Peter, this was actually helpful and enchanced my mental model.
I think I get get away for now with a user's tree rooted in the system
tree. My graphics environment (sway) can start necessary services
when it is started.

> > - Minor: a test utility for svscan dir would be nice
> > - Minor: a test utility for live dir would be nice
> 
> If you use s6-rc, those are the same directories, filled by s6-rc-init
> and changed by s6-rc-update. So the test would actually test those
> utilities, I guess.

By testing I meant checking if the directory has an active process
watching it. I believe there is a function in skalibs  fd_lock [1]
that svscan uses to check if another svscan runs there. I think it is
just a matter of exposing that function as standalone executable.

[1] https://github.com/skarnet/skalibs/blob/master/src/libstddjb/fd_lock.c


Ihor

Re: s6-rc as user service manager

[Laurent Bercot]

>Thanks Peter, this was actually helpful and enchanced my mental model.
>I think I get get away for now with a user's tree rooted in the system
>tree. My graphics environment (sway) can start necessary services
>when it is started.

  Yeah, it's a recurring discussion on the IRC channels, and my answer
is always that "user services" as systemd does them aren't a well-
defined concept - "logging in" doesn't always have a clear meaning:
do sshd logins count? Or only seat sessions? What happens when the same
user logs in via 2 different seats and 1 sshd, then logs out of one
seat? then of the second seat? Should the services be stopped, and if
so, when?
  systemd has to make choices and makes things work, more or less, in the
common case of one user at one seat - but that's a very unsatisfying
answer from a developer's point of view.

  s6 users are also more likely to log in remotely more often than
systemd users, so maybe systemd's choices aren't the best ones for s6.

  "User services" are a can of worms, and since I'm always very reluctant
to enforce policy on users or make choices that will not work in all
cases, it's not one that I'm willing to open beyond what's provided by
s6-usertree-maker.

  I'm happy that you can work with a permanent user tree - that is a
well-defined concept that can be implemented and wholeheartedly
supported with s6.


>By testing I meant checking if the directory has an active process
>watching it. I believe there is a function in skalibs  fd_lock [1]
>that svscan uses to check if another svscan runs there. I think it is
>just a matter of exposing that function as standalone executable.

  There are no executables to test whether s6-svscan or s6-rc are
running on a given directory, because these are not dynamic properties.
By policy, decided by you or your distro, you should *know*, at all
times, whether a given directory is a scandir with an s6-svscan running
on it - or whether a given directory is a livedir with s6-rc running
on it.
  If you think a given directory should have an s6-svscan running on it,
then you're right; ensure that s6-svscan is started at boot time, and
write your scripts assuming that it's there. If something fails because
it's not there, that's a bug or a system problem, and needs to be fixed,
not accommodated by your scripts.

--
  Laurent

Re: s6-rc as user service manager

[Ihor Antonov]

On 2022-10-18 00:58, Laurent Bercot wrote:
> > By testing I meant checking if the directory has an active process
> > watching it. I believe there is a function in skalibs  fd_lock [1]
> > that svscan uses to check if another svscan runs there. I think it is
> > just a matter of exposing that function as standalone executable.
> 
>  There are no executables to test whether s6-svscan or s6-rc are
> running on a given directory, because these are not dynamic properties.
> By policy, decided by you or your distro, you should *know*, at all
> times, whether a given directory is a scandir with an s6-svscan running
> on it - or whether a given directory is a livedir with s6-rc running
> on it.
>  If you think a given directory should have an s6-svscan running on it,
> then you're right; ensure that s6-svscan is started at boot time, and
> write your scripts assuming that it's there. If something fails because
> it's not there, that's a bug or a system problem, and needs to be fixed,
> not accommodated by your scripts.
> 

These tests made sense in the situation of user's services as systemd
does it. (Like answering a question whether another login shell has
already spawned svscan) It is indeed not necessary with static user
tree.

Ihor