Re: s6-svscan - controlling terminal semantics and stdin use

From: Earl Chew via skaware <>
Date: Tue, 2 Jan 2018 08:33:18 -0800

[ Colin, Casper, thanks for your suggestions ]


> we are not _certain_ there's no benefit from keeping stdin as is
Yes, I think that is a reasonable argument to leave it as is.
>  - The supervision tree isn't supposed to have a controlling terminal
Ok, I understand you're calling this out-of-bounds. I would suggest
calling this out clearly in the documentation. Perhaps something like:

    If you run s6-svscan from an interactive shell, be warned that
    typing ^C (ie sending SIGINT) from the controlling terminal will
    terminate the supervision tree and cause the supervised processes to
    become orphans.

>  - It is more beneficial to run services as their own session leaders
> by default
>  - The point of supervision is to increase reliability of services,
> not decrease it, so tearing down the supervision tree should generally
> not tear down services with it unless explicitly requested.
I do not think that my suggestion of placing the children of s6-svscan
in a separate process group from s6-svscan itself changes any of these
objectives. Each service would continue to apply its own session leader
role by default, and explicit requests to tear down the supervision tree
and the supervised processes should do just that.

The other thing I thought of is the asymmetry that although s6-svscan
handles SIGINT, I notice that s6-supervise does not handle this signal.
Perhaps this is a different point that could be considered. If
s6-supervise receives SIGINT, it could send SIGINT to the process group
it is supervising.

Do you think that is a reasonable to do?

Received on Tue Jan 02 2018 - 16:33:18 UTC

This archive was generated by hypermail 2.3.0 : Sun May 09 2021 - 19:38:49 UTC