>Ok, I understand you're calling this out-of-bounds. I would suggest
>calling this out clearly in the documentation.
Yes, I will update the documentation to clarify this, thanks for the
suggestion.
>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.
It doesn't indeed, but it's unnecessary. The supervision tree can be
seen as one entity, despite it being multiple processes; having the
s6-supervise processes in separate sessions or process groups does not
bring any benefits - quite the contrary, if you lose the s6-svscan
process and want to rebuild the supervision tree, you have to kill
every s6-supervise process by hand, which is tedious.
Really, since having a controlling terminal for the supervision tree
is a very uncommon case that should stay uncommon, I want it to have
the least possible amount of code dedicated to it, and to keep the
default Unix behaviour wherever possible.
>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.
See above - I don't particularly like s6-svscan handling SIGINT, and
wish I could leave it out entirely. Unfortunately, it's a requirement
for it to be able to run as process 1, since Ctrl-Alt-Del sends a SIGINT
to process 1.
--
Laurent
Received on Tue Jan 02 2018 - 17:15:39 UTC