So I'm stuck trying to handle a situation on a GoDaddy hosted account. Everything is wonderful, I'm really 99.9% pleased with the hosting and MySQL capabilities of GoDaddy over the client's previous hosting solution.
However, the 0.1% that is NOT happy, is causing some serious problem. Cron.
I can setup a cron job in the Hosting manager, but when GoDaddy fires off the command, it seems to re-fire the command every second until it gets what it wants or exceeds some retry cap (like 60+ retries apparently). This then seems to "lock" cron.php / the semaphore. But just removing the semaphore variable from the variable table doesn't fix it.
I went through this nice long walkthrough: http://drupal.org/node/360836 and it fixed it. Re-Enabling each module, updating if needed, then running cron.php manually, and then checking the cron entries in the log file - all completed successfully. Like 60+ iterations of re-enabling one or two modules each time. Everything was fine, until I re-enabled the GoDaddy cron.
The first time the GoDaddy cron it calls the cron.php through cURL, BAM it causes problems. I've tried variants of cURL, wGET, through http addresses, through local $HOME paths, everything.
(Supposition) It appears that when the GoDaddy cron fires off, it expects a local response in under 1 second, and retries the command every second for a minute (or longer). I base this on the long cURL retry output e-mail I get sent after a few minutes. I'm supposing that this is causing a problem with the cron.php and variables table. You'd think the semaphore would prevent multiple re-firings, but the ONLY time the cron.php gets "hung" or takes longer than a few seconds to run, is when GoDaddy's cron runs it. Period.
Like I said, I went through 60+ iterations of updating / re-enabling modules / re-running the status report / re-running cron from the admin interface, and re-checking the Log entries (filtered for Cron events), and they all completed fine. Until I re-enabled GoDaddy cron :(
If anyone has any thoughts on this, I appreciate it immensely (Jason, Bronius, Tall David, Efruin, etc...) :)
Thanks
Comments
poormanscron
Have you tried poormanscron (the module)? I suppose it's not the best solution for everything, but it might work out in this situation. If the problem lies with GoDaddy's cron service and not so much with the cron process itself in Drupal, then that may be a great way to get around the problem.
We originally had
We originally had poormanscron running. Then with the "new" host moved to GoDaddy, and the Cron Jobs support in Hosting panel, it just seemed the more "proper" way to go was to use a real cron, not a poormanscron.
But you are right, if I cannot get this fixed, I'll go through the whole "purge / re-enable" sequence again, get cron.php manually working fine, then re-enable Poormanscron and see if it works.
I just hate the inconsistency with Poormanscron, if the site isn't accessed over a weekend, and I needed something to run every day, it could be several days before it gets run with poormanscron :(
Hmmmm, wonder if poormanscron could set a timer to re-run itself at another interval....
I agree with you
That is certainly the downside of poormanscron, but if it's you're last resort, you're kinda stuck with it. : (
I like the idea of having poormanscron set a timer to re-run itself at some interval. Perhaps that should be suggested to the module developers - or written and submitted to them for inclusion in the module. Not sure if PHP and/or Drupal have a timer function built in, but I suspect they don't. That's why cron exists, right? : )
Just checking to see if you
Just checking to see if you have the computer plugged in :)
Normal cron has a minimum resolution of 1 minute. In the past I have made the mistake of setting the minute and forgetting to set the hour and it would have nearly the same symptoms you are having but instead of every second the script would run every hour at that minute.
Does GoDaddy have a 1 second resolution? And if so is it possible the configuration is the issue?
Julian
I purposely complicate what is simple, in order to simplify what is complicated.
It is GoDaddy's computer, if
It is GoDaddy's computer, if I can pull up the Hosting Control Center I would hope it is plugged in :)
The options on their cron system is minimal. Just a simple form with:
Cron job title: {text}
Frequency: {Hourly, Daily, Weekly, Monthly}
Command: {curl http://mydomain.org/cron.php}
Minute: {drop-down with 5 minute increments from x:00 through x:55 - when Hourly selected}
Save / Cancel
I have no other controls than that, at least not in the Basic interface. My supposition that it re-tries every second is based on the e-mail notification I get a few minutes later, which shows me x:00:01, x:00:02, ..., x:00:59 listing of retries with 0 0 0 0 0 0 0 0 0 entries for results table.
You've tried setting up the wget cron from a remote machine?
That would rule out (or confirm) local cron as an issue. Since you're using curl to call it, it really doesn't matter where you call it from.
I've not seen any issues like that myself.
remote call to cron.php unreliable service
He did, but I quoted too high a price to visit his site's cron.php from my Android phone.
Ironically, I have all of my
Ironically, I have all of my "test" cron entries in GoDaddy's Hosting Control Center set to "disabled" status right now. Yet somewhere, somehow, every x:00 and x:30 I am getting an Anonymous user hitting the site causing a "Type: cron" entry in the admin/reports/dblog. I don't recall if I set this up on another machine of mine while testing, or if it was something we did on the previous host before migrating to the new one. I need to examine the access logs to see if I can tell where the IP is coming from...
Anyway, when I was doing all the disabling and re-enabling it took maybe 4 hours or more altogether to do it - I was juggling a number of tasks, and it was a boatload of modules to do, so as I had 15 / 20 mins here and there I would go through a few more modules enable, cron, examine the dblog... During this time, I would see those "Anonymous x:30 and x:00" hits in the log, and they never caused a problem.
The problem started the second I enabled a GoDaddy cron and it hit the site's cron.php file, and got me back into a "locked" status. Now each of those "Anonymous x:30 and x:00" hits just create new entries in the dblog that show "Attempting to re-run cron while it is already running." and occasionally an entry saying "Cron has been running for more than an hour and is..."
I never had this problem, even when I would enable modules and run Cron at x:59, x:00, x:01 last night, I would have two entries for x:00, one Anonymous and one admin (me). But they never locked it up or caused a "...while already running" error/warning. This is why I'm just about convinced that somehow the GoDaddy cron is messing it up...
And I should note. The GoDaddy cron attempt, hangs it immediately - the status report shows "Cron Maintenance Task: never run" - so it never even completed once to log a good entry, it gets hung before it gets through, ever...
Had a similar issue
Here's how I handled it, but it looks like the google apps service that it depends on is no more.
You could set up cron on any machine that's connected whenever you need it to be. Even a home PC or dev machine.
On the other hand, are there really functions that need to be run in between visits to the site?