Re: s6-supervise: use of nosetsid

From: Guillermo <>
Date: Thu, 3 Dec 2020 16:56:06 -0300

El jue, 3 dic 2020 a las 13:47, Laurent Bercot escribió:
> I have previously added the "nosetsid" feature to s6-supervise, to
> address the issue: [...]. So when people want to manually
> test a supervision tree, they can have nosetsid files in their test
> service directories, and ^C will send a SIGINT to all the processes
> including the services, so everything will die, which is what they
> want.
> [...]
> Hence, my question to users: do you have a *valid* reason to use
> nosetsid files in your service directories?

I don't know if it is a valid reason, so I'll just tell what I
remember using these files for, and you judge :)

I happen to be one of those people who test service directories and
s6-rc service definitions by running s6-svscan in a terminal using
's6-svscan &' (and then s6-rc-init with a live state directory that is
not /run/s6-rc, and lots of -l options), and tearing down the
supervision tree using 's6-svscanctl -t .'. So no Ctrl + C in my case.

I remember occasionally using 'nosetsid' files for the convenience of
being able to redirect the output of 'run' and 'finish' to /dev/tty
(the controlling terminal of the shell I used to run s6-svscan) so
that I could see certain messages during tests in which s6-svscan had
its stdout & stderr redirected to a logger (typically, for emulating
an s6-linux-init-like s6-svscan-as-process-1 scenario). I think it was
for doing something like

foreground {
  redirfd -w 1 /dev/tty
  echo "Some message I want displayed on my terminal"

Having the supervised processes become session leaders meant that they
lost the controlling terminal, which, for X terminals, would be some
random special file in the devpts filesystem. Redirecting to /dev/tty
would not work in that case.

Granted, it is a rather obscure usage, and not a frequent one in my
case, but your mentioning of notsetsid files triggered the memory, so
I thought I'd mention that.

Received on Thu Dec 03 2020 - 19:56:06 UTC

This archive was generated by hypermail 2.3.0 : Sun May 09 2021 - 19:44:19 UTC