Re: s6-supervise: use of nosetsid

[Guillermo <gdiazhartusch@gmail.com>]

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.

G.