Re: shutdown on service unit timeout?

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Mo, 19.08.19 08:54, Chris Murphy (lists@xxxxxxxxxxxxxxxxx) wrote:

> Hi,
>
> Is it possible for a systemd service file to ask for a poweroff upon
> service timeout? If not, could it be done; or suggest an alternative?
>
> Here's the use case:
>
> No Screensaver/Powerdown after Inactivity at LUKS Password Prompt
> https://bugzilla.redhat.com/show_bug.cgi?id=1742953
>
> The summary is: plymouth waits indefinitely with a prompt for a
> passphrase, leads to excessive power consumption including battery if
> it's a laptop (it'll wait until the battery dies), and screen burn in.
> This can happen unattended if e.g. Fedora is the default boot, but the
> user dual boots Windows which has a tendency to wake up, do updates at
> "offline" times, and reboots... to Fedora where it waits indefinitely
> for a LUKS passphrase.
>
> I'm sure there are other examples. Plausibly anything that hangs
> during startup would have this behavior; only once we're at gdm (or
> equivalent on other DE's) is there a timer that will at least blank
> the screen, and possibly also optionally trigger suspend to RAM.
>
> Or alternative to a service unit opt in method, a way for systemd
> itself to opt into a "power off after X minutes unless Y process
> reports it's started successfully" type of behavior. In any case, it's
> up to the distro to decide the policy, with a way for the user to opt
> out of that by setting the applicable timeout value to something like
> 0, to indicate they really want an indefinite wait.

So, we have some logic for something like that (JobRunningTimeoutSec=,
JobTimeoutSec=, JobTimeoutAction=) and so on. But I am not convinced
we really should use that here...

The thing is: you can pull in LUKS devices any time, including during
run time long after boot-up (think: a backup disk is mounted right
before the backup script runs). A shutdown-on-timeout logic should
hence only be used during the early boot phase, but when this happens
while the system is up we should not. Thus I figure systemd-cryptsetup
should probably have code for this natively, maybe inspired what
systemd-fsck does, since it needs to be a tiny bit mor intelligent.

Happy to review a PR about this! ;-)

Lennart

--
Lennart Poettering, Berlin
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel