[systemd-devel] not running ExecStop= when stopping "activating" services?

Lennart Poettering lennart at poettering.net
Wed Apr 8 14:52:17 PDT 2015


On Fri, 20.03.15 12:43, Nekrasov, Alexander (alexander.nekrasov at emc.com) wrote:

> > This is intentional (see commit 3f6c78dc); I do not think intention was
> > as much "do not run ExecStopPost" as "do not spend time if starting
> > failed anyway"). There is currently no way to change it, it is
> > hardcoded. I guess you will need to present use case and explain what
> > is broken with current behavior.
> 
> [AN] here's the case. Often start-up of a service isn't just a one
> step, like starting a process. They need to bind LUNs, take locks,
> mount stuff, create structures, reformat DBs, create pid files,
> etc., before they want to report "ready" to the system. The main
> thing is, start-up is often a multi-step process, and the steps
> often make changes that are persistent. If that process is
> interrupted, there needs to be code run to make sure what's left is
> either cleaned up or made consistent. The kernel won't do the
> cleanup, so just killing off the processes in the c group isn't
> enough. The cleanup code also needs to be run after a failure, or a
> stop. Since systemd provides an ExecStop= option, that's an obvious
> place to hook cleanup code to, much like the catch section in a C++
> code. But for that to be useful, we must have a guarantee that the
> ExecStop will be called. There are obvious exception, such as the
> whole node crashing, where it won't be called, but that's
> understood.

Hmm, but there's ExecStopPost= for cases like this, isn't this enough?

Lennart

-- 
Lennart Poettering, Red Hat


More information about the systemd-devel mailing list