I've a Witty Pi 4 L3V7 connected to a Pi Zero 2 and a battery.
It has a schedule to regularly wake up the Pi, allowing to do some activities and then shutdown. This will happen at the end of those activities or as scheduled on “schedule.wpi”. This works very well.
However the Pi can also be booted manually with the button. When this happens the schedule is changed for witty to do a shutdown 1 minute before a startup, like this:
--------------- 2024-09-09 00:46:25 --------------- Schedule script is interrupted, revising the schedule... Schedule next shutdown at: 2024-09-09 00:49:00 Schedule next startup at: 2024-09-09 00:50:00 ---------------------------------------------------
If the pi is allowed to wait to shutdown to that time the witty crashes at the end of it. Without a working witty, the Pi zero also can't boot up using the button.
The only way to bring it to life is to disconnect it from all its power sources (battery and USB cable) and then booting up the Pi.
The immediate cause of the problem seems to be that my pi zero 2 needs more than 1 minute to shutdown. If the next startup schedule is during the shutdown the witty crashes or is locked and this happens.
I've solved the problem, in my end, by changing a line (155 in your private repo, 162 on GitHub) of `runScript.sh` that inserts the 1 minute, from:
# schedule a shutdown 1 minute before next startup setup_on_state $((check_time-duration-60))
to
# schedule a shutdown 1 minute before next startup setup_on_state $((check_time-duration-600))
Giving now 10 minutes for the shutdown.
I don't if it's a good solution for all systems or is there anything better to solve this, but is a problem that should be addressed to avoid this problem in older systems.
Thanks for sharing your solution, and I guess it will help others who has similar situation.
However I want to mention that taking very long time (more than 1 minute) to shutdown should not be considered as a normal scenario. Even if a old/slow Raspberry Pi is used, shutting down the system should not take that long. If it does, that usually indicates some other issues that worth to be checked.
We will not officially do the same fixing, because there is no a "good" value for us to use. 60 seconds are already long enough for a healthy system to shutdown, 600 seconds may work for you, but that may be still not enough for another (unhealthy) system.
There is another reason that we don't want to change that value: the bigger value it uses, the higher chance that the "schedule revising" can't work: with a bigger value it is easier to set the schedule shutdown to a time in the pass, which causes the schedule stop working. For example, if you manually wake up your Pi 7 minutes before the scheduled startup, with your modification it will set the shutdown 10 minutes before scheduled startup, which make it in the pass and will never happen.
You could try to make the schedule revising smarter, but eventually there will be some scenarios that still have problem.
I've a Witty Pi 4 L3V7 connected to a Pi Zero 2 and a battery.
It has a schedule to regularly wake up the Pi, allowing to do some activities and then shutdown. This will happen at the end of those activities or as scheduled on “schedule.wpi”. This works very well.
...
The immediate cause of the problem seems to be that my pi zero 2 needs more than 1 minute to shutdown. If the next startup schedule is during the shutdown the witty crashes or is locked and this happens.
Why is your Pi so slow to shut down? Do you have a clue?
---
I have the same gear. A Pi Zero 2W and a Wittypi 4 L3v7. It runs 32-bit Bookworm Lite. The main software is Pihole and Unbound. Plus Chrony for local NTP services to LAN clients (I have to enable Chrony @reboot, as Witty Pi disables all NTP, but enabling @reboot worked out OK).
The OS is on a SanDisk SD card High Endurance, but I still prefer to use log2ram and zram-swap-config to avoid wearing down the SD card. When the Pi shuts down or reboots, logs will be synchronized from memory to SD card, which probably takes time.
I have limited the size of the journal and currently the shut down time is not too long. I've still set the power cut delay to the max. 25 sec. to be on the safe side (battery low voltage value is 4,2 V so on a black-out it shuts down right away).
I haven't timed the shut down time with the current setup, but in my earlier attempts I used different zram software (the one with /etc/ztab) and it seemed to be the culprit of long shutdown times. Long shutdown times will lead to the UPS suddenly cutting off power after max. 25 seconds, which, if happening a lot, IMO will sooner or later destroy the OS on the SD card. I think it did in my case, but I cannot prove it. Perhaps it was something else. I lost faith in that installation.
So I figured it wiser to start setting up totally anew from scratch. This second time I chose log2ram and zram-swap-config, which seemed to work faster at syncing.
This is all unfortunately sketchy and experimental. I would like to be able to test other zram and logging to ram software a lot more, but I don't have the time nor energy for it. The Pi currently fulfills its purpose, viz. local DNS server with NTP service for local clients including the router. It is rebooted every night and up to now, there hasn't been a problem. Next Thursday my internet connection will be cut for a number of hours - but not AC power - and I'll see how my LAN survives.
After I read here on this forum about the beforeShutdown script, I figured it could serve to *shorten* the shutdown time by shutting down some software *before* the actual shutdown command is issued and the power cut delay countdown starts. It would in a way circumvent the maximum power cut delay value. This was on the second (final) installation. I tried several options, shutting down unbound, pihole and chrony in the beforeShutdown script, but the results weren't conclusive and currently I don't have anything in beforeShutdown.