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

Michael Biebl mbiebl at gmail.com
Tue Feb 3 11:50:39 PST 2015


2015-02-03 20:36 GMT+01:00 Martin Pitt <martin.pitt at ubuntu.com>:
> Lennart Poettering [2015-02-03 18:10 +0100]:
>> I am very strongly against adding hacky work-arounds like this to PID
>
> Yeah, indeed. This is why I asked for a more elegant approach, and
> indeed the --no-block or --job-mode=ignore-dependencies sound like
> slightly better approaches to this. I'll test these more thoroughly
> tomorrow, thanks for pointing out!

The current patch we ship in Debian is admittedly not the nicest one,
but it solves a very real issue which affects a lot of non-trivial
setups.

>> 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.
>
> Right, the problem is of course more generic. Any set of jobs (i. e. a
> transaction) which causes (maybe through some indirection) one of its
> job members to get restarted/reloaded will suffer from this deadlock
> problem, AFAIUI. Booting and shutdown are therefore mostly affected by
> this as pretty much every other time there the pending transactions
> are only very small.
>
>> 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.
>
> That actually sounds like just what's needed here. is-system-running
> will also neatly cover the corresponding case on bootup.
>
>> 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...
>
> For reload that should be fairly okay, as reload will quickly fail if
> the unit isn't actually running, and if it is running its dependencies
> already ought to be satisfied.
>
> I'll look into both, thanks for the hints!

Keep in mind though, that you'll need to not only update "service",
but also invoke-rc.d and the lsb-hook, which is used when someone
calls /etc/init.d/foo directly.

It's also magnitudes less efficient to spawn external binaries to get
the system state then doing this check from within systemd itself.

So I'm not really convinced that shifting the responsibility here to
the scripts themselves is the better approach.


Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?


More information about the systemd-devel mailing list