Re: s6-supervise: use of nosetsid

From: eric vidal <>
Date: Fri, 4 Dec 2020 08:25:03 +1100

On Thu, 03 Dec 2020 16:46:58 +0000
"Laurent Bercot" <> wrote:

> Hello,
> The next version of s6 will be a major bump, with a few long-awaited
> QoL changes - mainly a thorough cleanup of how s6-svscan handles
> signals and the various commands sent by s6-svscanctl, but also some
> goodies that you should like. :)
> One issue that has been often reported by users is that when they
> try running s6-svscan in a terminal, and then ^C to kill it, the
> services remain running. This is intentional, because supervision
> suites are designed to isolate processes from anything accidental that
> could bring them down, and in particular services should normally
> survive supervisor death - but so far there has been many more
> instances of people having trouble with that behaviour than instances
> of s6-supervise accidentally dying.
> I have previously added the "nosetsid" feature to s6-supervise, to
> address the issue: having a "nosetsid" file in a service directory
> prevents the service from being started as a session leader, it starts
> in the same session as the supervision tree (and, if the nosetsid file
> is empty, in the same process group). 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.
> There are two problems with the nosetsid approach:
> - Oftentimes, users are not aware of the existence of nosetsid, and
> still experience the issue. It's almost an s6 FAQ at this point.
> - The nosetsid functionality is inherently a risk: it puts the
> whole supervision tree at the mercy of a misbehaved service that would
> send a signal to its whole process group. There is a reason why
> s6-supervise normally starts services in a different session, and
> nosetsid bypasses that safety measure.
> So I am thinking of another approach to make s6 friendlier to users
> who would - despite it not being recommended behaviour - test a
> supervision tree in a terminal: have s6-supervise handle SIGINT and
> make it kill its service before exiting. That would ensure that ^C
> cleans up everything.
> This approach has the drawback of making services a little less
> resilient, but s6-supervise getting a SIGINT should *only* happen in
> the case of someone running a supervision tree in a terminal, which
> is absolutely not something that should exist in production, so it's
> probably not a big concern. However, it comes with a major advantage:
> it removes the original reason for the addition of nosetsid.
> So, with the change to ^C handling, I am considering removing the
> dangerous nosetsid functionality entirely.
> Hence, my question to users: do you have a *valid* reason to use
> nosetsid files in your service directories? Are there use cases for
> nosetsid that I have not thought about, and that would make using s6
> impractical if the functionality were to be removed?
> Thanks in advance for your input.
> --
> Laurent

I never used the nosetsid file.

Even for people who want to test a service with a fresh scandir from a terminal, i provide the necessary tools to properly start and stop the scandir without the need to hit the ^C key.

So no valid reason from my part to use this files.

Your commit simplify a lot the s6-svscan interface which is a great thing.

eric vidal <>
Received on Thu Dec 03 2020 - 21:25:03 UTC

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