[systemd-devel] [PATCH] Avoid reloading services when shutting down

[Lennart Poettering]

On Tue, 03.02.15 18:01, Martin Pitt (martin.pitt at ubuntu.com) wrote:

> Lennart Poettering [2015-02-03 17:29 +0100]:
> > Hmm, why precisely does this stall for 90s? 
> 
> The current transaction has final.target and all other jobs which need
> to be shut down. One of these now trigger "systemctl reload
> postfix.service", but that reload isn't going to actually run in the
> same transaction but in the next one. OTOH systemctl reload
> waits for the reloading to finish, thus we have a deadlock.
> 
> > Isn't this a case where people should just use "--no-block"?
> 
> Kind of. Not using this is the right thing while the machine is
> running, so that the reload is actually done after calling systemctl
> reload, and you can go on using postfix or whatever. --no-block should
> help during shutdown, or early boot (same principal bug, but slightly
> different patch, see http://bugs.debian.org/624599).
> 
> So every time you call reload you'd have to check whether or not you
> are in early boot/during shutdown, or in the running system, and
> conditionally use --no-block. However, as such scripts should never
> call systemctl directly, but "service foo reload" (to work with other
> init systems or chroot), it would be also possible to move that check
> there, and conditionally add --no-block. It would just be another
> thing that every distro has to re-discover :-)

I am very strongly against adding hacky work-arounds like this to PID
1. The deadlocks are deadlocks, and implying --no-block if we are in
shutdown mode is a pretty drastic hack I think that special cases one
peculiar case way too much.

My recommendation would be to stick this into your /usr/bin/service
compat glue. Use the state string "systemctl is-system-running"
outputs to check if you are shutting down. If so, add --no-block to
the params you pass to systemctl.

Another option might be to pass --job-mode=ignore-dependencies instead
of --no-block, which was created for usecases like this, even though
it is frickin' ugly...

Lennart

-- 
Lennart Poettering, Red Hat