[ 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?

> mailto:earl_c...@yahoo.com

Reply via email to