s6-rc: dependencies across scandirs

s6-rc: dependencies across scandirs

[Sertonix]

Hi, I would like to have some kind of dependency handling across
multiple scandirs.

For example an instanced service that starts and waits for a dependency
before the first instace has been started.

I think s6-svc -WU -u could do that to some extend. There would be
problems though if the dependency is forced down.

A more complicated variation I would like to have is a user service
depending on a system service (and starting it!). For example a user
service for sway depends on the system service for seatd.

I think this would't work with s6-svc at all. This could probably be
done with some ipc client/server similar to s6-sudo.

Is there any simple and safe way to do something like this?

Re: s6-rc: dependencies across scandirs

[Laurent Bercot]

>Hi, I would like to have some kind of dependency handling across
>multiple scandirs.
>
>For example an instanced service that starts and waits for a dependency
>before the first instace has been started.

  It's generally a bad idea to add, in a service's run script itself,
conditions for your service to work, or to restart. It tends to make
your service *less* reliable, instead of *more*.
  Supervision is about keeping the services up, not monitoring when they
should or should not run. The latter is for service management.

  Instead, design your services so they exit if they have unmet hard
dependencies. The supervisor will try to bring them up again and again,
and it will eventually work, when the dependencies are resolved. The
job of avoiding too much looping, again, belongs to a service manager.


>A more complicated variation I would like to have is a user service
>depending on a system service (and starting it!). For example a user
>service for sway depends on the system service for seatd.

  Start your sway. If seatd isn't up, sway will exit, and the supervisor
will restart it. This works as intended.

  Now, start propagation is a different question, and a more difficult
one, because it crosses privilege boundaries. Do you want users to be
able to start system services? To stop them? In the general case, no,
you certainly don't.

  In this particular case, you probably want seatd to be controllable
by the user at the console. That's what s6-svperms is for:
https://skarnet.org/software/s6/s6-svperms.html

  When relevant (at user login time? earlier?) make seatd controllable
by a group only the console user is in. Then you can simply add a
s6-svc -u for seatd in your sway run script, if that's what you need.

--
  Laurent