]> git.ipfire.org Git - thirdparty/systemd.git/commit
logind: respect "delay" inhibitors in scheduled shutdowns
authorAlan Jenkins <alan.christopher.jenkins@gmail.com>
Mon, 21 Aug 2017 16:28:35 +0000 (17:28 +0100)
committerAlan Jenkins <alan.christopher.jenkins@gmail.com>
Thu, 24 Aug 2017 11:42:54 +0000 (12:42 +0100)
commitdf75a1a8aa5420335a56093077fa8cfcbfffac78
treee791c15bfd8d529bcc9ef7bef5e842c5b3526861
parentb498d6ea9f72520c579035928d16c527d992bca8
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/
src/login/logind-dbus.c