[systemd-devel] race conditions after SIGTERM

Lennart Poettering lennart at poettering.net
Thu Aug 14 10:51:01 PDT 2014

On Thu, 14.08.14 21:38, Andrei Borzenkov (arvidjaar at gmail.com) wrote:

> > Which is what we do. Except when you specify ExecStop= which basically
> > tells systemd that you want to do it instead. So there you go!
> Those daemons I have seen are terminated after receiving signal/command
> to do it. Those sysvinit scripts that "synchronously" terminated
> services did it by implementing wait for daemon process to exit. What
> is worse, the only way to do it is busy looping as they cannot normally
> receive notification about process exit.

Well, if they don't have such a protocol, then they can use systemd's
default logic for this, and just tweak the parameters. KillMode=,
KillSignal=, TimeoutStopSec= are all ways how you can control how
exactly systemd should terminate your service.

> Compare this with "send daemon command - signal or whatever - and wait
> until it exits". This needs to be implemented just once in PID 1 - and
> PID 1 already does exactly this most of the time anyway. Why is this
> the wrong thing to do? You never explained this when you rejected my
> patch.

Hmm, this is what we do. By specifiying ExecStop= you turn that off
however can plug in your own logic. If you don't have any better logic,
then simply don't plug anything in, that's what we recommend anyway.

Again: systemd does what you want it to do by default, anyway. By
specifiying ExecStop= you however turn this off, and have to do it on
your own!


Lennart Poettering, Red Hat

More information about the systemd-devel mailing list