supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit
 help / color / mirror / Atom feed
From: "Laurent Bercot" <ska-supervision@skarnet.org>
To: Sertonix <sertonix@posteo.net>, supervision@list.skarnet.org
Subject: Re: s6-rc: dependencies across scandirs
Date: Wed, 03 Jan 2024 12:35:37 +0000	[thread overview]
Message-ID: <emcd883d57-7637-42b1-8741-d8e190a25944@e425fad0.com> (raw)
In-Reply-To: <CY4BWQ3FTACT.12W6FR5G8I9YK@posteo.net>

>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


      reply	other threads:[~2024-01-03 12:35 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-02 15:34 Sertonix
2024-01-03 12:35 ` Laurent Bercot [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=emcd883d57-7637-42b1-8741-d8e190a25944@e425fad0.com \
    --to=ska-supervision@skarnet.org \
    --cc=sertonix@posteo.net \
    --cc=supervision@list.skarnet.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).