Skip to content
Commit df75a1a8 authored by Alan Jenkins's avatar Alan Jenkins
Browse files

logind: respect "delay" inhibitors in scheduled shutdowns

There is no justification not to wait an extra (default) 5 seconds, for
a more graceful shutdown of user programs.  Again, you don't get to ignore
delay inhibitors for unscheduled shutdowns, short of
`systemctl poweroff -f`.

It is simplest if we move the test for `m->shutdown_dry_run` into
manager_scheduled_shutdown_handler().

However we need to not add such delays during a "dry run".  Otherwise, we
would still have to be considered "in progress" for some seconds after our
admin has seen the final wall message.  If they go to `poweroff`, we would
have blocked them with a misleading error message.  Note this `poweroff`
will still process delay inhibitors as needed.  If the admin planned to
use a more forceful method... eh.  It's their responsibility to assess
whether that's safe.

There is an argument that the alternative behaviour could be used (racily!)
to kludge around them not being able to shutdown to "single user mode".  If
we cared about that case, we would have easily preserved non-racy support
for it in `shutdown`.

Additionally, though I think this code does read more easily by reducing
inconsistencies, we didn't come up with any use case for delay inhibitors
v.s. shutdown.[1]  The SIGTERM v.s. SIGKILL delay is more general, and we
allow a whole 90 seconds for it, not just 5.  So I don't think keeping this
approach bears a risk of significant damage.

[1] https://www.freedesktop.org/wiki/Software/systemd/inhibit/
parent b498d6ea
Loading
Loading
Loading
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment