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

["Ulrich Windl" <Ulrich.Windl@xxxxxxxxxxxxxxxxxxxx>]

>>> Silvio Knizek <killermoehre@xxxxxxx> schrieb am 18.02.2022 um 09:37 in
Nachricht <7d547aa30624f2dc8d22ea7f84507fa1d8e9c678.camel@xxxxxxx>:
> Am Donnerstag, dem 17.02.2022 um 10:50 +0100 schrieb Ulrich Windl:
>> > > > Lennart Poettering <lennart@xxxxxxxxxxxxxx> schrieb am
>> > > > 16.02.2022 um 18:17
>> in
>> Nachricht <Yg0xkENt8XNvo+y4@gardel-login>:
>> > On Mi, 16.02.22 14:09, Ulrich Windl
>> > (Ulrich.Windl@xxxxxx‑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
> ---

Thanks Silvio!

That looks like I was after. But admitted: I had expected that systemd could
do some of the "shell scripting magic" (like counting and comparing).

Regards,
Ulrich


> 
> HTH
> Silvio