I recently had a problem with cron on one of my Drupal sites, related to an issue I'll be posting about soon (namely, using Drupal's built-in search with more than 4.5 million entries in the search_index table). When I manually tried running cron, I got a "Cron failed" status message. I checked the log, and it said "Attempting to re-run cron while it is already running."
Apparently, something had messed up (probably due to the fact that I was messing with database tables while cron was working on them) with the previous cron job, and Drupal couldn't start a new cron job anymore. So, with the handy help of Google, I found part of a solution to my cron woes in the Drupal.org forums. Here's what I did to prevent this cron error from happening again:
- In PHPMyAdmin (you can also do this manually via the command line), delete the following rows from the variable table:
- cron_last
- cron_semaphore
- On your Drupal site, clear all the cache tables (If you have Administration menu installed, you can just click the "Flush all caches" link in the site-wide links menu).
As always, make sure you backup your database before you start deleting rows from it!
Now, cron is running without a problem again. There are some other issues I'm still having with cron, though, mostly related to the indexing of content via the built-in search.module. I'm working on fixing this problem, and right now am testing the use of InnoDB instead of MyISAM tables in MySQL to see if indexing goes any faster. (Thanks dmckenna!).
Comments
I am certainly no expert on cron but as far as I recall it the cron_semaphore is pretty important. I read a couple of posts saying that you should delete when cron is stuck but after a successful run you should put it back. You might want to investigate this.
It seems that the semaphore exists simply to tell Drupal that cron is running. If you know that cron has been running for a long time (longer than your PHP timeout), then you can safely delete this value in the database; it should only appear while cron is running. (At least, that's what I've read on d.o, and in the API...).
The semaphore prevents cron.php from running more than one instance concurrently. Just don't delete it while cron is working ;-)
The devel module also includes a variable editor that I've used to delete those variables when needed.
Kyle - I've not used the Devel module all that much, but that's good to know! (I typically don't use it on a live site, and the site in question needed to be fixed quick, so I found it easiest to simply go in through PHPMyAdmin).
I am facing problem in cron because of Search module. If I disable Search module then cron works well.
I checked phpmyadmin, in variable table there is no row for cron_semaphore. Is this is a problem?
How should I solve this problem? Please assist
@ chanakya: You might want to check out the SuperCron module - it will let you separate the search cron functions from the other cron functions, and hopefully solve your dilemma.
I've had search trouble, too, especially when the number of nodes on one of my sites gets pretty high (in the multi-thousands). Hopefully future improvements to Drupal's core search indexing will fix this, but for now, try SuperCron.
Also, the semaphore value isn't always going to be in that table; it's usually only there during the time the cron run is happening; if the cron run errors out, the semaphore is usually removed at the time of the error.
I had the same problem but installing the SuperCron module definitely fixed it. You definitely need to check it out. Jamie
supercron is one clever solution, it worked for me with poormanscron after this patch:
http://drupal.org/node/485458
poormanscron and supercron modules can work together now
this was the only way that could manage and rearange invokes on your system. experiment with multithread option and rearangements, try enabling multithread on time consuming procedures and move them to the top
not sure if needed, but all of them after commons.inc hack, just for the first normal cron run
http://www.digitaledgesw.com/node/21
// Fetch the cron semaphore//$semaphore = variable_get('cron_semaphore', FALSE);
$semaphore = FALSE;
after a successful cron run, revert commons.inc back to original
no need to delete any rows in variables table,
for manual cron run:
do not run original cron from now on as it could produce semaphore locks again, use supercron's invoke all instead
You bring up an interesting solution, no doubt - it's pretty easy to fix using the commons.inc hack - but for some people, it might be quicker to ssh in and delete the variable directly ;-)
Poormanscron has gotten a lot nicer since last time I used it!
thanks for recommending supercron, it fixed cron run failures and was quick to install :)
SuperCron did not fix my problem. running cron gives me this error..related to the site Search module (when i disable that module, cron runs).
Fatal error: Class 'view' not found in /var/www/drupal6/includes/common.inc(1685) : eval()'d code on line 3
Anyone have ideas how to fix it?
I found the problem - a node with apparently invalid php code. Thanks.
Ah - very good!