Hi Patrick,
> I'm running s6 in a terminal to control some software under development.
> My workflow is, run s6-svscan, watch logs directed to stdout in my
> terminal window, ctrl-c to bring everything down.
>
> I may be misdiagnosing, but I think what happens is ctrl-c results in
> SIGINT being sent to all processes in the group, which in this case
> includes the s6-supervise processes. They exit (SIGINT is not handled),
> and leave the service process running (now a child of pid 1).
>
> It would be convenient for my development workflow if s6-supervise
> handled SIGINT in the same way as SIGTERM. I've attached a (trivial)
> patch that does just that, but I don't know if there are unintended side
> effects. Thoughts?
I'm reluctant to add SIGINT handling to s6-supervise because it's
not meant to be used with a controlling terminal, so there's no
reason for it to ever have to do something special with SIGINT, it should
just do the default thing, i.e. die without trying to be smart.
What is hurting your workflow is that your service processes *do not*
receive the SIGINT as s6-svscan and s6-supervise do, because s6-supervise
creates a new session for them.
Try having a file named "nosetsid" in your service directories: then
s6-supervise will run your service processes in the same session, and they
should eat the SIGINT as well. And die.
--
Laurent
Received on Tue Apr 08 2014 - 22:19:59 UTC