s6-svscan - controlling terminal semantics and stdin use

From: Earl Chew via skaware <skaware_at_list.skarnet.org>
Date: Mon, 1 Jan 2018 19:53:39 -0800

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
Received on Tue Jan 02 2018 - 03:53:39 UTC