[systemd-devel] Antw: [EXT] Re: [systemd‑devel] Q: Perform action for reboots happen too frequently?

Silvio Knizek killermoehre at gmx.net
Fri Feb 18 08:37:48 UTC 2022


Am Donnerstag, dem 17.02.2022 um 10:50 +0100 schrieb Ulrich Windl:
> > > > Lennart Poettering <lennart at poettering.net> schrieb am
> > > > 16.02.2022 um 18:17
> in
> Nachricht <Yg0xkENt8XNvo+y4 at gardel-login>:
> > On Mi, 16.02.22 14:09, Ulrich Windl
> > (Ulrich.Windl at rz.uni‑regensburg.de)
> wrote:
> >
> > > Hi!
> > >
> > > I wonder: Is it possible with systemd to detect multiple reboots
> > > within a specific time interval, and react, like executing some
> > > systemctl command (that is expected to "improve" things)?  With
> > > "reboots" I'm mainly thinking of unexpected boots, not so much
> > > the
> > > "shutdown ‑r" commands, but things like external resets, kernel
> > > panics, watchdog timeouts, etc.
> >
> > The information why a system was reset is hard to get. Some
> > watchdog
> > hw will tell you if it was recently triggered, and some expensive
> > hw
> > might log serious errors to the acpi pstore stuff, but it's all
> > icky
> > and lacks integration.
>
> Lennart,
>
> you got me wrong: I don't want to filter on the reasons of the
> (re)boot, but I
> just wanted to rule out any possible solution that stores information
> during an
> orderly shutdown/reboot ;-)
>
> >
> > A safe approach would probably to instead track boots where the
> > root
> > fs or so is in dirty state. Pretty much all of today's file systems
> > track that.
>
> In the past (when there are a few logins only) I would have been
> tempted to
> use "last" to grep for boots, but if there are many (automated)
> logins, those
> boots may be "rolled out" and thus won't be counted possibly.
>
> >
> > It sounds like an OK feature to add to the systemd root fs mount
> > logic
> > to check for the dirty flag before doing that and then using that
> > is
> > hint to boot into a target other than default.target that could
> > then
> > apply further policy (and maybe then go on to enter
> > default.target).
> >
> > TLDR: nope, this does not exist yet, but parts of it sound like
> > worthwile feature additions to systemd.
>
> Something very primitive:
> a) Increment some counter on every boot, and reset that counter after
> some
> time.
> b) Check the counter and if it is >= some threshold, execute a one-
> shot
> command
>
> Could systemd help with a) and b)?
>
> Regards,
> Ulrich

Hi Ulrich,

so, incrementing a counter and executing stuff should be easy.
Something like

--- boot-counter.service
[Unit]
Description=Incrementing the boot counter
RequiresMountsFor=/var/lib
DefaultDependencies=no

[Service]
Type=oneshot
Environment="T=5"
ExecStart=/usr/bin/bash -c 'declare -i c="$(< /var/lib/boot.counter)"; c+=1; echo "$c" > /var/lib/boot.counter'
ExecStart=/usr/bin/bash -c 'if (($(< /var/lib/boot.counter) > T)); then /clean-script.sh; fi'

[Install]
WantedBy=multi-user.target
---

For the reset you can employ a .timer and a .service

--- reset-boot-counter.timer
[Unit]
Description=Reset boot counter after 30 minutes

[Timer]
OnBoot=30m
AccuracySec=1us

[Install]
WantedBy=timer.target
---

--- reset-boot-counter.service
[Unit]
Description=Set /var/lib/boot.counter to zero
RequiresMountsFor=/var/lib

[Service]
Type=oneshot
ExecStart=/usr/bin/bash -c 'echo "0" > /var/lib/boot.counter
---

HTH
Silvio


More information about the systemd-devel mailing list