[ Colin, Casper, thanks for your suggestions ]
Laurent,
> 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?
--
Earl
> mailto:earl_chew_at_yahoo.com
Received on Tue Jan 02 2018 - 16:33:18 UTC