On Thu, 03 Dec 2020 16:46:58 +0000 "Laurent Bercot" <ska-supervis...@skarnet.org> 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 https://github.com/skarnet/s6/commit/bdef68e12278ddfc5080732bd3b28dd5135c9d3a simplify a lot the s6-svscan interface which is a great thing. -- eric vidal <e...@obarun.org>
