2018-01-02 0:53 GMT-03:00 Earl Chew: > > My first observation is that when killing the cron initiated s6-svscan > process with SIGINT or SIGTERM, I see the behaviour described in the > documentation. The child s6-supervise processes are correctly > terminated, and there are no orphans. > > If instead, I start s6-svcscan at the terminate and terminate it with ^C > (SIGINT), what I observe is that the child s6-supervise processes > terminate abruptly and their child service processes are orphaned. > [...] > > Has this scenario (ie starting s6-svscan from an interactive terminal) > been considered previously? > > My expectation was that the two scenarios would exhibit similar behaviours.
Do you really need s6-svscan to run in the foreground, or do you just want to gracefully tear down the supervision tree in this case? What I do if I want to use s6-svscan from an interactive shell is: $ s6-svscan /path/to/scandir & (shell returns a job control job ID) $ (Do whatever I need to do with the supervision tree) $ s6-svscanctl -t /path/to/scandir With a suitable .s6-svscan/finish file, of course. This mostly works like when launching s6-svscan in any other way (except perhaps for the environment, as Casper pointed out). No special arrangement with nosetsid files needed. Using kill(1) with the job ID returned by the shell (i.e. kill %some_number) to send a SIGTERM signal instead of using s6-svscanctl works too, provided that s6-svscan was invoked without the 'divert signals' option, -s. G.