[systemd-devel] At wits end... need to execute a script prior to anything getting killed/changed on reboot/shutdown

[Jonathon Kowalski]

On Thu, Jan 17, 2019 at 4:49 AM Christopher Cox <ccox at endlessnow.com> wrote:
>
> On 01/16/2019 10:44 PM, Christopher Cox wrote:
> > On 01/16/2019 12:51 PM, Filipe Brandenburger wrote:
> >> If you want to run it early in the shutdown process, then keep
> >> DefaultDependencies=yes, in which case it will run before the base
> >> dependencies start to get stopped.
> >>
> >> If you need some other resources to be up, for instance network, then add
> >> After=network.target, etc.
> >>
> >> Remember that when shutting down, the dependencies are stopped in the
> >> opposite order as they're started up, so if you need your script to run
> >> *before* something else is stopped, then you need an After= dependency.
> >>
> > But only for services under systemd.  Everything else gets sprayed a TERM
> > signal.  Which is frustrating.  So... having it execute first doesn't
> > guarantee (and we're talking less than a second or so) that it will have time
> > to do what it needs to do before the kill spray happens, and I need all
> > processes to be around until my script finishes.
> >
> > Old sysvinit didn't have this limitation.
>
> Adding some extra systemd clarification.  Saying do this After or Before other
> service doesn't mean the start/stop completes before moving on.  It may execute
> asynchronously before/after, but processes aren't done synchronously.
>

This isn't right. systemd's ordering is purely defined for jobs in
queue. If your start job is ordered after another unit's start job,
then it really will wait for the other start job to complete before
dispatching yours. This may produce erroneous results if you don't
configure the readiness of the service you wait on correctly, but that
isn't a systemd issue at that point. Similarly, if a stop job for it
gets enqueued, it will walk the reverse dependency and add one in
queue for yours too, and yours will become runnable before the other
one does, and as long as you're stopping, the other unit's stop job
keeps waiting on you atleast (if nobody else) in queue.