chiark / gitweb /
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)
committerSven Eden <yamakuzure@gmx.net>
Mon, 25 Sep 2017 12:33:49 +0000 (14:33 +0200)
commit121b6e868e29da661885f7a8100b603fc7212046
tree8a9db667db7616a6613fea46bddd97ce2b58147d
parentf14477bc2a519635ab07eb22e48c52993268756f
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/elogind/inhibit/
src/login/logind-dbus.c