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: supervision@list.skarnet.org
Subject: Re: s6 xinit replacement?
Date: Sun, 15 May 2022 01:52:11 +0000	[thread overview]
Message-ID: <em4f33f378-f039-4f53-889f-dbb91ed57c4b@ac898acf.com> (raw)
In-Reply-To: <3GMPPUYHIEJBK.3F20HQJFLEHMP@oak.localdomain>

>Is the purpose of executing setsid() in s6-supervise to allow for the
>services to continue beyond the termination of the supervision tree?

  It's actually the opposite: it's to protect the supervision tree
against misbehaved services. :) setsid() makes sure the service is
isolated, and a killpg() or equivalent won't affect anything outside
of it. Of course, it also protects *other* services running under the
same supervision tree.


>If that's the case, could there possibly be a flag to disable that,
>with the understanding that something like nohup or even s6-setsid would
>be necessary to replicate that behavior?  That would enable a non-root
>Xorg to be managed by s6.

  The direction s6 has taken is really the opposite: there was such a
flag in earlier versions, but it was causing a lot of special cases
and problems I definitely did not want to deal with.
  The real issue is that a supervision tree should not be run with a
controlling terminal. It's not meant to be run from a logged-in user
process, but as a background infrastructure that's always there. The
whole point of s6 is to make your services *more reliable*; and there
are few things less reliable than a whole tree of processes that can
die on an accidental ^C.

  Because users insisted a lot, there are still accommodations for
killing a whole supervision tree with ^C when s6-svscan has been 
launched
in a terminal. It is a nice feature to have (and although it was by 
design
that services persisted beyond the ^C, it was unintuitive to most users,
so from a pure UI standpoint, killing the entire tree in one go was
better).
  However, I'm not going back on the "each service runs in its own 
session"
thing, because if there's a case for allowing the user who controls
s6-svscan to kill the whole tree at once, there is just no case for
allowing a service running under the tree to impact other services and
the tree itself.

  Despite this, you're right that the pattern of xinit is similar to what
s6 does, and it *is* possible to run Xorg under s6; several users are
doing so, and I hope they will post their setup. (You may have more
luck by asking in the IRC channel, but it would be nice for the setup
to be documented on the mailing-list.) It does not involve running
s6-svscan from your own VT; it involves having a supervision tree
already running (as your user), and starting the Xorg service, e.g.
with a s6-svc -u command, on a given VT, possibly passed to the run
script via a file that your xinit emulation script would fill in
with the output of `tty`.

  If you insist on doing hacky things, you could even probably get away
with something that looks like:

xinit emulation:
#!/bin/sh
tty | sed s:/dev/tty:: > /home/me/.screen-number
s6-supervise /home/me/Xorg &
# small race here that disappears when s6-supervise has already run once
s6-svwait -U /home/me/Xorg
your-X-client
s6-svc -dx /home/me/Xorg

/home/me/Xorg/notification-fd:
3

/home/me/Xorg/run:
#!/bin/execlineb -P
backtick -E screen { cat /home/me/.screen-number }
export DISPLAY :$screen
X -displayfd 3 :$screen vt$screen

-displayfd is used as a notification mechanism, unblocking s6-svwait
when the X server is ready.

  Hope this helps (and I hope users who actually have done something
similar will share their experience),

--
  Laurent


  reply	other threads:[~2022-05-15  1:52 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-11  3:36 dallinjdahl
2022-05-14  3:47 ` Guillermo
2022-05-14 23:45   ` dallinjdahl
2022-05-15  1:52     ` Laurent Bercot [this message]
2022-05-15 15:02       ` Guillermo
2022-05-17  4:10         ` Rio Liu
2022-05-15  2:44   ` Samuel Holland
2022-05-22 15:07     ` Guillermo
2022-05-22 16:33       ` Samuel Holland
2022-05-23 10:05       ` yianiris
2022-05-23 23:40         ` Guillermo
2022-05-27  2:04         ` Steve Litt
2022-05-28  4:07     ` Dallin Dahl
2022-05-28 17:15     ` Dallin Dahl
2022-05-28 19:43       ` Samuel Holland

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=em4f33f378-f039-4f53-889f-dbb91ed57c4b@ac898acf.com \
    --to=ska-supervision@skarnet.org \
    --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).