Thanks for the s6-* family of programs. I've just started using s6-svscan for some deployments.
In one of the scenarios, I was prototyping the behaviour of s6-svscan over a supervision tree directly at the interactive terminal for use in a cron-based scenario. My first observation is that when killing the cron initiated s6-svscan process with SIGINT or SIGTERM, I see the behaviour described in the documentation. The child s6-supervise processes are correctly terminated, and there are no orphans. If instead, I start s6-svcscan at the terminate and terminate it with ^C (SIGINT), what I observe is that the child s6-supervise processes terminate abruptly and their child service processes are orphaned. I think the issue is that the child s6-supervise processes continue to be part of the same process group as s6-svscan, which in turn is attached to the controlling terminal of the session. The SIGINT is delivered to all the processes in that group, which terminates the s6-supervise processes immediately, thus causing their children to become orphaned. Has this scenario (ie starting s6-svscan from an interactive terminal) been considered previously? My expectation was that the two scenarios would exhibit similar behaviours. I was thinking about how to go about making the two scenarios more alike. Using s6-setsid as part of the */run supervision scripts seems like a solution, but it will not have the right effect since what is required is not to create a process group for the */run process, but to dissociate the s6-supervise from process group of s6-svscan. This means that any potential remedy would have to be placed around the fork() in s6-svscan. AFAICT s6-svscan does not require that all its children reside in the same process group as s6-svscan. So an approach would be to either place each s6-supervise process in its own process group, or to create another process group for them all to reside in. My second observation is that stdin of s6-svscan is inherited by all its s6-supervise children. I'm wondering if there is anything to be gained by that, and whether it would be less surprising to set stdin to /dev/null after fork() since having a herd of processes attempting to read from the same stdin does not seem to lead anywhere useful. What do you think? Earl