[Nixie]

What's a workaround for the infamous cron falling asleep bug at http://www.dd-wrt.com/wiki/index.php/CRON#CRON_Service_falling_asleep_in_V24 ?
I was thinking of making cron restart itself, but I don't know if that's possible. If I add a cron job that, say every hour, does stopservice cron && startservice cron, would the compound command run fully, or will it interrupt when the stop part executes? (I assume it would run through if it's launched in a separate process, but would not if it runs within the cron process.) Any alternatives?

[cabbage]

Thanks for the link. I get this problem and had assumed it was my hardware. I was about to buy a new router..!

Anyway, as a workaround I added the following as a startup command:

[yoyoma2]

Occasionally my cron jobs stop running on my up to date stable kong build. Here's a simple cron watchdog shell script that detects the problem and restarts cron service only when it's asleep. This solution is similar to this one but runs on dd-wrt itself and doesn't require a server with php.

I run the script every hour on the hour from Administration->Management->cron with this line:

[yoyoma2]

More info on this cron falling asleep issue. This cron watchdog script has shown that cron falls asleep between 5 to 8 hours following a scheduled reboot (enabled in Administration->Keep Alive->Schedule Reboot). A random power outage a couple of days ago shows that cron does not fall asleep after a hard reset as it does hours after a scheduled reboot.

My current test is to disable scheduled reboots and put the same command that would be in /etc/cron.d/check_schedules into Administration->Management->Cron->Additional Cron Jobs instead. If that works, great. If it doesn't work, I'll try to issue the reboot differently.

It appears that the cron falling asleep bug is actually more of a scheduled reboot bug.

[yoyoma2]

I've managed to reproduce the cron falling asleep bug on demand.

1) Power off the ISP's modem (unplug ethernet cable may work too)
2) Reboot dd-wrt

At this point dd-wrt runs ntpclient periodically to try to set the clock. My setup actually sets the clock at bootup with gps so it's pretty close. During this time dd-wrt and all its processes including cron run perfectly for as long as you want.

3) Power on the ISP's modem

After a few minutes the modem will get an internet connection and share it by DHCP with dd-wrt and ntpclient will succeed in setting the clock.

Result)

All cron jobs, which may have been running for hours, will never run again. The cron process is "asleep" and needs to be restarted for any cron jobs to run again.

Theory)

There's a race condition between cron and ntpclient at startup and if ntpclient comes in second, it can mess up a working cron.

Edit)

During one test, the ISP took an unusually long time to connect the modem. During this delay, dd-wrt's cron still fell asleep after receiving only a local IP address through DHCP from the modem and ntpclient was still trying/failing on dd-wrt. It would seem ntpclient is not the culprit for messing up cron but rather something dd-wrt does when receiving an IP address on the WAN port.

[giles02134]

I thought I'd try the simplest approach first, so I added Cabbage's startup command. So far, the router is rebooting itself as scheduled, at 3:00 a.m.

Thanks for all the useful information in this thread.

[yoyoma2]

I prefer the watchdog script workaround since it won't restart cron unless it's found to be "asleep". Don't know what might happen if a cron restart occurred in the middle of cron already running something.

I've added the replication steps from this thread to this bug. Hopefully, now that there are replication steps, BrainSlayer will solve the underlying problem and cron asleep workarounds will become moot.

[giles02134]

That's an excellent point, and I'll likely follow your suggestion. I was mainly interested in a "Proof of Concept", that sleepy CRON was indeed the problem.

Thanks again for your help!

[giles02134]

Not sure my PMs are getting sent...still have messages in my "Outbox".

The script is running as a background process. However, it seems that the cron instance doesn't run. If I run it once from the command line, the cronwd.txt files is created, and then is updated every hour on the hour. Otherwise, the cronwd.txt file never appears.

Auto-reboot is working, but no explanation for why the cron job doesn't fire off on it's own.

Nothing in the cronwd.log.

[Alozaros]

well, in witch build cron is not working i can see
mine's is fine and there are services going on and off on regular, basses...

[giles02134]

My version is listed below.
There has been a problem on and off through many versions, where cron either dies, or falls asleep. In my situation, the auto-reboot wasn't working.

Apparently, sleepy/dying cron has been an issue for some time, at least with some routers/versions.

[yoyoma2]

[giles02134]

What yoyoma2 said.

The work-around shell script that yoyoma2 has shared in this thread,(about which I'll post more later this week) works really well at poking cron with a stick when it dies or falls asleep.

As I noted earlier, the symptom for me was that the scheduled reboot wasn't working. Until yoyoma2 pointed out that cron was the likely culprit, I assumed the reboot issue was a bug in its own right.

Indeed, the cron issue needs to be fixed, as DD-WRT, like any Linux system, depends on it. I'd be happy to see old bugs fixed ahead of new functionality being added, but that's just my opinion.

As I am in no way a systems developer/programmer, I'll have to wait and see.

[yoyoma2]

Posted a fix for this cron bug in the Contributions Upload forum here. Until the developers submit this/another fix, the watchdog script in this thread is a usable workaround.

[egc]

Thanks I just reviewed it and I think you are definetly on to something.