A “simple” task to schedule a power off of an OpenWrt Router took 3 hours….
That is a quirk: cron uses a log function in busybox that has no input for error levels and is fixed to log everything as an “error.” Consequently every log entry by cron will be tagged cron.err, whether it is an actual error or not.
In other words, BusyBox logging lies…. at hour 2, I finally realised that.
The fix is to change the log level, but not via the GUI, because the Log Level dropdown does not persist.
Then, it gets stuck in a Device Reboot Loop.
So I managed to trigger my poweroff command via Cron (so it was a scheduled task),
30 12 * * * poweroff
Turns out that most Routers don’t have a Real Time Clock, which means at bootup…
In the boot process the clock is initially set by sysfixtime to the most recent timestamp of any file found in /etc. The most recent file is possibly a status file or config file, modified maybe 30 seconds before the reboot initiated by cron. So, in the boot process the clock gets set backwards a few seconds to that file’s timestamp. Then cron starts and notices a few seconds later that the required boot moment has again arrived and reboots again…
The fix? 30 12 * * * sleep 70 && touch /etc/banner && poweroff
But why do you want to power off the router?
I do a power shutdown overnight, as I’m (a) not using the network, and (b) saves electricity.
I’ve found that OpenWrt does not tolerate an unclean shutdown. My TP-Link router hangs on power-on. So a scheduled poweroff before the electricity is turned off fixes the unclean shutdown problem.
And finally … each Starlink runs an NTP server based on GPS time
Yes, each Starlink runs an NTP server based on GPS time, which can be accessed by configuring your NTP client to use 192.168.100.1. The time is based on GPS; however, we cannot guarantee accuracy as the service is provided on a best-effort basis.
Except when the GPS in the Dish fails. And StarLink will not fix it.
