[systemd-devel] [PATCH] man: document kill behavior after the main process exits

[Lennart Poettering]

On Thu, 23.04.15 09:43, Daniel Drake (drake at endlessm.com) wrote:

>                                                  
> 
> On Thu, Apr 23, 2015 at 9:32 AM, Lennart Poettering
> <lennart at poettering.net> wrote:
> >> +    <title>Beyond the main process</title>
> >> +
> >> +     <para>The <varname>KillMode=</varname> option primarily defines
> >> +     behavior up until the point where the main process has gone away.
> >> +     systemd expects that when killed with the signal specified by
> >> +     <varname>KillSignal=</varname>, the main process will kill and
> >> +     reap all the other processes in the control group before
> >> +     exiting itself.
> >
> > Well, I don't think this is right. I mean, systemd doesn't really
> > "expect" this. It's completely OK if daemons leave children around in
> > this case.
> 
> I could avoid the word "expect" but I think it's worth mentioning as
> those discarded children might not be designed to accept 2 SIGTERMs in
> "normal" conditions.

Well, ideally we'd make KillMode=mixed the default these days, which
avoids the confusion around this. However I doubt we should change
this now.

> For example, any child process that uses glib and exits the mainloop
> from the SIGTERM handler does not really respond well here - it drops
> the SIGTERM handler after the first one, so the second SIGTERM will
> cause an immediate/unclean shutdown, which is not "completely OK" from
> the view of the child.

Well, then mention this explicitly: say that if the main daemon
process does leave child processes around and KillMode=control-group
is set, that those child processes might get two SIGTERM in sequence.

> >> +     <para>If <option>KillMode=control-group</option>, systemd will
> >> +     then send a second <varname>KillSignal=</varname> signal to the
> >> +     remaining processes, which will then be followed by a
> >> +     <constant>SIGKILL</constant> if processes are still around, even
> >> +     if <option>SendSIGKILL=no</option>.</para>
> >
> > Hmm, no? SendSIGKILL=no should have the effect of not sending any
> > SIGKILL at all. Anything else would be a bug.
> 
> Must be a bug then; I confirmed this is actually what happens by
> adding logging to the kill syscall implementation in the kernel.

would be happy to see this tracked down. SendSIGKILL=no should really
do what it suggests it does!

Lennart

-- 
Lennart Poettering, Red Hat