>Has this scenario (ie starting s6-svscan from an interactive terminal)
>been considered previously?
Yes. The default behaviour was chosen considering this:
- The supervision tree isn't supposed to have a controlling terminal
- 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.
But you can tell s6-supervise to run its service in the same session
as the supervision tree by touching the ./nosetsid file in the service
directory. If all your service directories have a ./nosetsid file and
s6-svscan has a controlling terminal, ^C on s6-svscan will kill
everything as you expect.
>My second observation is that stdin of s6-svscan is inherited by all
>its
>s6-supervise children. I'm wondering if there is anything to be gained
>by that, and whether it would be less surprising to set stdin to
>/dev/null after fork() since having a herd of processes attempting to
>read from the same stdin does not seem to lead anywhere useful.
You are wondering if there is anything to be gained by that. I am
wondering, too; I suspect there's a case in s6-overlay where it's
useful, because one early service actually uses data from this stdin
(but I'd need to check the s6-overlay code to be sure).
The point is, we are not _certain_ there's no benefit from keeping
stdin as is. And redirecting stdin to /dev/null is very easy to do for
a user, but impossible to reverse if it's hardcoded in a program: so
enforcing the redirection would restrict what users can do without a
significant usability improvement.
So, the best choice is to do nothing. In the general case, users will
run "s6-svscan < /dev/null", which is not difficult to remember (and
this is also what s6-linux-init's stage 1 does).
It is with redirections as it is with forks: users can easily do them,
but cannot undo them. So it's best to leave the choice to the user.
--
Laurent
Received on Tue Jan 02 2018 - 10:50:24 UTC