[systemd-devel] Antw: [EXT] Re: [systemd‑devel] Intercepting/Delaying the boot process

[Lennart Poettering]

On Mo, 11.04.22 07:56, Ulrich Windl (Ulrich.Windl at rz.uni-regensburg.de) wrote:

> >>> Lennart Poettering <lennart at poettering.net> schrieb am 08.04.2022 um 15:14 in
> Nachricht <YlA1LldVyl2GGI1N at gardel-login>:
>
> ...
> > This reminds of an RFE we have had for a while, and which I think
> > would make sense to add directly to systemd: a generator that detects
> > whether the battery is nearly empty at boot, and if so redirects boot
> > to some special target showing a nice message for a bit and then
> > powering off.
>
> Why does it have to be a generator; can't a normal unit detect and handle that?

Sure. But it should be nicer to move the whole system into a specific
state for such cases, so that services explicitly have to opt-into
running in that state (by means of enabling themselves in the
low-battery.target unit), instead of all being pulled in, and waiting
forever in the queue. After all, in such a low battey case you want to
waste as little resources as you can, hence when the state is detecte
you really just want to bring the message to screen and then shut down
after a while, and not start a myriad of low-level system services.

(Also, for robust embedded devices you probably want to put an overall
timeout on the boot process via JobTimeoutSec=+JobTimeoutAction= on
multi-user.target. And that would collide with any scheme where we
just stall the boot process for a long time)

Lennart

--
Lennart Poettering, Berlin