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
Received on Tue Jan 02 2018 - 10:19:02 UTC