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

[Daniel Drake]

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.

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.

> KillMode= is actually very much about the time after the main process
> died. If KillMode=process is specified systemd should not send any
> signal to anything but the main process, and that applies to both
> SIGTERm and the following SIGKILL:

I agree, which is why I specifically only talk about the cgroup/mixed
kill modes.

>> +     <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.

>> +     <para>Or, if <option>KillMode=mixed</option>, systemd will
>> +     directly send <constant>SIGKILL</constant> to all remaining members
>> +     of the control group, regardless of the
>> +     <varname>SendSIGKILL=</varname> preference.</para>
>
> Hmm? No, not at all. If you use "mixed", then SIGTERM is is sent to
> the main process of the daemon, and SIGKILL to *al* processes of the
> daemon if there are any left after the main process exited.

That's exactly what I wrote - all of this falls under a paragraph
explaining what happens when the main process has already gone. I
guess I need to improve the wording.

Thanks for your feedback

Daniel