On Mon, Jan 01, 2018 at 07:53:39PM -0800, Earl Chew via skaware wrote: > 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.
Perhaps you can try the `-s' option of s6-svscan? > 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. (Actually s6-supervise does setsid() by default before exec()ing into its supervised process; there is an optional `setsid' control file to disable this behaviour.) > 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. I think `s6-svscan /path/to/sevices < /dev/null' should be enough? -- My current OpenPGP key: RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19) 7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C