Bug#834164: systemd: Services are not killed after a timeout or killed immediately after ExecStop

Felipe Sateler fsateler at debian.org
Sun Aug 14 16:37:20 BST 2016

On 13 August 2016 at 05:12, Dark Penguin <darkpenguin at yandex.ru> wrote:
>> In short, you need to make your ExecStop wait for the process to exit.
>> The manpage in later versions is more explicit in this regard:
>>             Note that it is usually not sufficient to specify a
>>             command for this setting that only asks the service to
>>             terminate (for example, by queuing some form of
>>             termination signal for it), but does not wait for it to do
>>             so. Since the remaining processes of the services are
>>             killed using SIGKILL immediately after the command exited,
>>             this would not result in a clean stop. The specified
>>             command should hence be a synchronous operation, not an
>>             asynchronous one.
> Oh! I actually missed it. This clarifies it, thank you! Indeed, it's not a
> bug, but a "feature" then. :)
> However, I have no way to make it synchronous (without pretty bad kludges).
> Let's say my service behaves much like ftp in this example. It doesn't seem
> to be an uncommon situation when you're trying to run as a service something
> that doesn't provide any other way to shut down gracefully other than
> sending a stop command via its console. I could put a whole script waiting
> for the process to die in the ExecStop= line, but this is a workaround (and
> quite an ugly one); supporting so many types of service startup and
> shutdown, surely systemd has a simpler way to deal with this situation?..

I don't think so. If you think this is a common scenario, please file
this at the upstream issue tracker:

> By the way, is there a way to actually see the result of systemctl actions
> immediately? When we tried to restart, for example, bind9 with SysV scripts,
> we saw enough information: "stopping... passed - it was not running;
> starting... failed". With systemctl, I have to invoke "status" after every
> command because I run a command and I get zero output - even if the command
> actually failed and the service did not start and is now in a failed state!
> There may be a reason for this, which I am also curious about, but maybe
> there is an option to enable output from all systemctl commands, at least if
> they fail?..

No, there isn't. There is an upstream request for this


Felipe Sateler

More information about the Pkg-systemd-maintainers mailing list