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.

Reply via email to