Hi, recently switched from dd-wrt to OpenWrt (Openbreaker 14.07 with LuCI) and I'm really excited by the possibilities so far.

Ran into a little hiccup while trying to do a scheduled reboot today though.

As a test I added "x y * * * reboot" to Scheduled Tasks via LuCI, where x y were a couple minutes away from the current time.

Cron didn't reboot the router until I discovered that I had to restart Cron to force it to process the crontab change. That's a pretty minor bug.

The bigger problem was when it did finally work: After the router rebooted, it then rebooted again. And again. And again. It is as if the reboot happened so quickly that cron didn't get around to noting that it had already ran the command, so decided to do it again after the reboot.

So the router entered the wonderful world of infinite loops, and I had to reset the router and reconfigure it all again. I decided to see if I could replicate the issue so I again entered a scheduled task, but this time I used "x y * * * sleep 70 && reboot" to give myself some time to login and kill the process. Good thing I did, because it happened again. Fortunately with the sleep delay I was able to look up the process and kill it before the next reboot.

Anyone care to see if they can replicate this behavior and/or know a way to fix it?

Thanks,
Chris

(Last edited by ceb1970 on 27 Nov 2014, 07:15)

The real-time clock does not progress during the boot process. After boot the clock initially starts from the most recent timestamp of any file in /etc. At the end of the boot process ntpd starts and gets updated time from internet. You may notice this time jump in the system log, although ntpd starts so late that there might not be anything in the log after that.

Most likely in the boot process, the most recent file is a status file, config file or something, modified maybe 30 seconds before the boot. So, in the boot process the clocks gets set backwards a few seconds to that file's timestamp. And then cron notices a few seconds later that the required boot moment has arrived and reboots again :-(

Best solution might be to instead of "sleep 70" use "touch" command to update a file's date in /etc to "now + 2 minutes". E.g. /etc/banner is harmless and is there. Then after the boot, the time starts definitely from "after the boot moment". Examples in http://superuser.com/questions/122863/l … relatively

I recommend checking uptime before reboot.

You guys are awesome!  I went with hnyman's idea of touching /etc/banner. However I kept the sleep 70 just in case. Why risk an infinite loop if it doesn't work?

So my final cron entry in Scheduled Tasks looks like this:

# Reboot at 4:30am every day
# Note: To avoid infinite reboot loop, wait a minute
# and touch a file in /etc so clock will be set
# properly on reboot before cron starts.
30 4 * * * sleep 70 && touch /etc/banner && reboot

Thanks for the help guys!

Ultimately it would be great if a patch could be added to automatically touch /etc/banner when reboot runs so no one else runs into a similar issue. Also, when Scheduled Tasks is updated and Submitted, cron should be restarted so the change to crontab will be applied.

Yes, I know... "Make the patches yourself and submit them" I'll add that to my list.

I know this is an old thread, but seems that ceb1970 posted the seed of all forums over the web regarding a daily reboot of an OpenWRT/LEDE router using cron, so this looks as the best place to keep all together.

Some concerns arose in some forums regarding if the daily touch in /etc/banner will ware out it's flash memory (it won't, will probably last faaaar more than 10 years with a daily touch on any modern router) and _DS_ suggestion wasn't explored, so here is that alternative to the simple touch solution:

# Reboot at 4:30am every day
# Note: To avoid infinite reboot loop due to not persistent clock,
# make sure if the system hasn't rebooted within last 1000 minutes
30 4 * * * sleep 70 && uptime | awk -F'( |,|:)+' '{if ($7=="min") m=$6; else {if ($7~/^day/) {m=$9+$8*60+$6*60*24} else {m=$7+$6*60}}} {if (m+0>=1000) {system("reboot")}}'

I left "sleep 70" because doesn't hurt and just in case we need it, and used "awk" for parsing the Busybox v1.25.1 "uptime" answer and executing the system reboot. Any further suggestions?

(Last edited by Langus on 8 Mar 2018, 22:02)

In some cases there really may be difference between 30 4 * * * sleep 70 and 31 4 * * * sleep 10 )

It may be bulletproof to wait for the correct time, but I don't think this is really needed, as long as you don't need to reboot your router exactly at the same time you have modifed something at /etc/config, or maybe in /etc ;-) I reboot like 50 routers using cron and never hit this. If someone works that early in the morning, he would probably prefer to reboot router in the evening ;-)

Just reboot your router, run logread and you will see what time it uses at boot. Simply cron few minutes sooner and you have 24 hours to login even if router fails to sync. (https://www.youtube.com/watch?v=jeV-vTMhXO8)