Re: [systemd-devel] [PATCH] man: document kill behavior after the main process exits
On Thu, 23.04.15 09:20, Daniel Drake (dr...@endlessm.com) wrote: -timeout, if the normal shutdown procedure left processes of -the service around. Takes a boolean value. Defaults to yes. +timeout, if the normal shutdown procedure didn't succeed in +shutting down the main process. Takes a boolean value. +Defaults to yes. I think this really should clarify that this is about leaving processes around. /para/listitem /varlistentry @@ -163,6 +164,31 @@ /refsect1 refsect1 +titleBeyond the main process/title + + paraThe varnameKillMode=/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 + varnameKillSignal=/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. 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: If that doesn't happen, and the main process + exits with other processes still running in the control group, + systemd gets a bit more heavy-handed:/para I'd prefer not using words like heavy-handed here. + + paraIf optionKillMode=control-group/option, systemd will + then send a second varnameKillSignal=/varname signal to the + remaining processes, which will then be followed by a + constantSIGKILL/constant if processes are still around, even + if optionSendSIGKILL=no/option./para Hmm, no? SendSIGKILL=no should have the effect of not sending any SIGKILL at all. Anything else would be a bug. + + paraOr, if optionKillMode=mixed/option, systemd will + directly send constantSIGKILL/constant to all remaining members + of the control group, regardless of the + varnameSendSIGKILL=/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. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] man: document kill behavior after the main process exits
On Thu, Apr 23, 2015 at 9:32 AM, Lennart Poettering lenn...@poettering.net wrote: +titleBeyond the main process/title + + paraThe varnameKillMode=/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 + varnameKillSignal=/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. + paraIf optionKillMode=control-group/option, systemd will + then send a second varnameKillSignal=/varname signal to the + remaining processes, which will then be followed by a + constantSIGKILL/constant if processes are still around, even + if optionSendSIGKILL=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. + paraOr, if optionKillMode=mixed/option, systemd will + directly send constantSIGKILL/constant to all remaining members + of the control group, regardless of the + varnameSendSIGKILL=/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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] man: document kill behavior after the main process exits
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: +titleBeyond the main process/title + + paraThe varnameKillMode=/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 + varnameKillSignal=/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. + paraIf optionKillMode=control-group/option, systemd will + then send a second varnameKillSignal=/varname signal to the + remaining processes, which will then be followed by a + constantSIGKILL/constant if processes are still around, even + if optionSendSIGKILL=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
[systemd-devel] [PATCH] man: document kill behavior after the main process exits
While looking at the exact behavior of how systemd stops services, I encountered some behavior that wasn't clear from reading the man page. Specifically, if the main process exits before its children, the child processes will actually receive a second SIGTERM. If that doesn't kill them, they will later receive a SIGKILL too, even if SendSIGKILL=no. Add some notes about this. --- man/systemd.kill.xml | 30 -- 1 file changed, 28 insertions(+), 2 deletions(-) Thanks for helping me to get to the bottom of this in the thread: Zombie process still exists after stopping gdm.service unit_kill_context() has a comment which is relevant here: /* FIXME: For now, we will not wait for the * cgroup members to die, simply because * cgroup notification is unreliable. It * doesn't work at all in containers, and * outside of containers it can be confused * easily by leaving directories in the * cgroup. */ /* wait_for_exit = true; */ When this is fixed, assumed to happen soon, the precise behaviour seen in the discussion will change slightly (in terms of timing). So I have carefully written this documentation patch in a way that does not go into the timing details. The text changed below should therefore be true both before and after that FIXME is resolved. diff --git a/man/systemd.kill.xml b/man/systemd.kill.xml index e57f0e7..10232fb 100644 --- a/man/systemd.kill.xml +++ b/man/systemd.kill.xml @@ -154,8 +154,9 @@ termvarnameSendSIGKILL=/varname/term listitemparaSpecifies whether to send constantSIGKILL/constant to remaining processes after a -timeout, if the normal shutdown procedure left processes of -the service around. Takes a boolean value. Defaults to yes. +timeout, if the normal shutdown procedure didn't succeed in +shutting down the main process. Takes a boolean value. +Defaults to yes. /para/listitem /varlistentry @@ -163,6 +164,31 @@ /refsect1 refsect1 +titleBeyond the main process/title + + paraThe varnameKillMode=/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 + varnameKillSignal=/varname, the main process will kill and + reap all the other processes in the control group before + exiting itself. If that doesn't happen, and the main process + exits with other processes still running in the control group, + systemd gets a bit more heavy-handed:/para + + paraIf optionKillMode=control-group/option, systemd will + then send a second varnameKillSignal=/varname signal to the + remaining processes, which will then be followed by a + constantSIGKILL/constant if processes are still around, even + if optionSendSIGKILL=no/option./para + + paraOr, if optionKillMode=mixed/option, systemd will + directly send constantSIGKILL/constant to all remaining members + of the control group, regardless of the + varnameSendSIGKILL=/varname preference./para + + /refsect1 + + refsect1 titleSee Also/title para citerefentryrefentrytitlesystemd/refentrytitlemanvolnum1/manvolnum/citerefentry, -- 2.1.0 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
