On Thu, 23.04.15 09:43, Daniel Drake (dr...@endlessm.com) wrote: > > > On Thu, Apr 23, 2015 at 9:32 AM, Lennart Poettering > <lenn...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel