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

Reply via email to