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
