By everydayjones on

Are you having the issue listed in the subject? Really!? Me too! Well, I was....for about 3 months!

I racked my brain and read SOO many help requests with little to none help. Here's how I fixed my issue:

1. Open up your PHPMyAdmin (if using a shared hosting company it'll be in your CPanel or backend interface)
2. Click on SQL and run this command:
SELECT * FROM variable WHERE name like "cron%"

If you see anything with "cron" on it, delete it by clicking on the checkbox and selecting the red X

3. Go to CACHE table, click on BROWSE, DELETE the VARIABLE field (just select the checkbox and click the red X)
4. Go to Administer > Modules and disable EVERY module (minus the Drupal Core).
5. Open up a new browser window and navigate to Administer > Logs > Status Report
6. Open up another new browser and navigate to Administer > Logs > Recent Log Entries and choose the drop down box and select CRON MESSAGES and click FILTER
7. Start enabling one module at a time.
8. After enabling ONE module, go to the browser that has STATUS REPORT and click on RUN CRON MANUALLY
9. Notice the TIME. If the time is more than a few seconds, there is something wrong.
10. If there is something wrong, open up the browser that has the RECENT LOG ENTRIES and click on the FILTER. See if you're getting the same error.
11. If you ARE getting the same error, you must repeat steps 2 and 3. THIS IS CRUCIAL! If you DON'T complete steps 2 and 3 when you get this error, you will ALWAYS get this error.
12. Once deleted again, you can click on RUN CRON MANUALLY again and you shouldn't get an error.
13. The next steps are to keep enabling modules one at a time. Each time you enable a module, you MUST click on RUN CRON MANUALLY to see if the error appears. If it appears, run steps 2 and 3.
14. Do this until all modules are enabled. For the ones causing errors, GET RID OF THEM!

Questions? Send me an email jason@everydayjones.com and I'll be glad to help (as much as I can).

Hopefully someone will sticky this or google will pick it up!

Good luck!

-Jason

⋅ Categories: Drupal 5.x

Comments

everydayjones’s picture

everydayjones commented

The two modules that were causing me errors were:

Mailout 5.x-1.x-dev
Mime Mail 5.x-1.0

eotinfotech’s picture

eotinfotech commented

Dear Jason

How you are using the cron on your drupal installation ?
1. cpanel system cron
or
http://drupal.org/project/poormanscron

?

Regards, and Have a nice day.

Prachait Saxena
---------------------------
(M) :- +91 9953 200 299
(W) :- http://www.eotinfotech.com/

everydayjones’s picture

everydayjones commented

I have cron set up in my CPanel

hocu’s picture

hocu
he/him
commented

thanks for this useful troubleshooting tutorial.

actually steps 1, and 2 were quite enough for my website. i do not have this problem at the moment.

mestato’s picture

mestato commented

Thanks a whole bunch, clear directions like this are always an awesome find!

mestato’s picture

mestato commented

Another good set of cron diagnostic tricks is here: http://drupal.org/node/123269. The search module was causing my problems and turning it off then on seems to have fixed it.

mhaag’s picture

mhaag commented

delete from variable where name = 'cron_semaphore';
delete from variable where name = 'cron_last';

tomsm’s picture

tomsm commented

Thanks, your tips are very helpful!

hacmx’s picture

hacmx commented

Well, finally I could solve my problem with your guide, Thank You very much!

cswan’s picture

cswan commented

Step 1 and 2 were very helpful. Thank you very much!!!

okokokok’s picture

okokokok commented

I'm on Drupal 6, the DELETE stuff didn't work, but this did:

drush --yes vset cron_semaphore 0

jvieille’s picture

jvieille commented

subscribe

JV

rwsimmo’s picture

rwsimmo commented

"drush --yes vset cron_semaphore 0" worked for me. Thanks!

cancerian7’s picture

cancerian7 commented

Thank you so much :)

nyo01’s picture

nyo01 commented

I'm so relieved I didn't have to go past step 2 in my case on Drupal 6.19.
Thanks so much!

lukus’s picture

lukus
he/him
commented

Thanks for the tips.

I ended up deleting the rows referencing cron from the variables table, and then just flushed my cache in the usual manner.

This solved the problem for me.

Anonymous’s picture

Anonymous (not verified) commented

I just wasted the better part of an hour trying to troubleshoot a "cron run failed" error on one of my Drupal sites (oddly, only one of four was affected). Trying to run cron manually from the status page gives a "cron run failed" error, and looking at the "Recent log entries" (aka watchdog, apparently) showed a message "Attempting to re-run cron while it is already running".
I did a bit of searching for a resolution to this, there is a bit of discussion about this on the main Drupal site, and at least one other site. You will notice in both places, that a suggested fix is to use phpMyAdmin to manually delete the "cron_semaphore" and "cron_last" from the variables table.
cron_semaphore is, indeed the culprit, but in my case, deleting the cron_semaphore from the database did not help. All I can think of, is that the database query result was being cached s.t. even though cron_semaphore was not set in the database, PHP was still picking it up. To fix this, what I ended up doing was temporarily modifying common.inc drupal_cron_run() to disable the semaphore entirely:

 // Fetch the cron semaphore
  //$semaphore = variable_get('cron_semaphore', FALSE);
  $semaphore = FALSE;

Making this change disables the semaphore mechanism entirely and allows cron to run. After doing this, I checked the variables table and sure enough the cron_last variable could be seen to be updated. I then re-enabled the semaphore (put the original common.inc back) and so far, everything seems to be o.k.
Note that some of you reading this might be tempted to just leave the semaphore disabled. And if you can be 100% certain you'll never get two crons running at the same time, it is probably safe to do so. I wouldn't recommend it though; instead, think of this as an emergency measure to get the cron_semaphore un-stuck when doing so using the database method doesn't work.

stuartEngelhardt’s picture

stuartEngelhardt commented

Thanks, I tried many of the other options and manual fixes. But following this technique revealed an underlying jquery library dependency that was not showing up in other admin interfaces until I re-enabled things one by one. Now it all works.

fmilland’s picture

fmilland commented

Thanks a lot, it worked for me

rajmataj’s picture

rajmataj commented

For the last few days, more and more of my Drupal sites were failing to run their daily cron. The hosting company I'm with investigated for a while but nothing changed, until today when they wrote:

I was analyzing the changes made to server and we had optimized the MySQL server
for better performance. So the variables that we had made changes were
wait_timeout and connection_timeout values along with max_allowed_packet. We
have changed these values and set upper values. Please run the crons and see if
this helps complete the backup cron process.

Indeed, this did solve the issue, so if you're completely stumped, be aware of these variables and perhaps ask your host about them.

ledelboy’s picture

ledelboy commented

Thanks. I have two sites with this issue. Both are multilingual. Te culprit was the translation suite. I can survive very well without it, but chron is a total must.

alejob86’s picture

alejob86 commented

Thanks for the post!

I am using Drupal 7.

I did follow steps 1 and 2 however in step 3, I could not find any registry associacted with "cron". I then went to the "SEMAPHORE" table and delete the "cron" registry. The it works!!

This may help someone.

Thanks again.

skilip’s picture

skilip commented

For D7:

1. Enable the Devel module
2. Navigate to devel/php

db_delete('variable')
  ->condition('name', array('cron_semaphore', 'cron_last'), 'IN')
  ->execute();
coredumperror’s picture

coredumperror commented

Thank you! THIS is the actual instructions I needed for Drupal 7. Apparently D7 doesn't use the "cron_semaphore" variable any more, and instead uses the semaphore table, like you mentioned. Deleting the cron entry in the semaphore table is what actually worked.

gomes.mr’s picture

gomes.mr commented

:)

Thank you!!!
Thank you!!!
Thank you!!!
Thank you!!!

citkane’s picture

citkane commented

Thanks - your post saved me a whole lot of head scratching and is still valid for Drupal 7.

Just to add - I 'broke' Drupal Cron by accidentilly running a recursive chmod (permissions) through my www folder (luckily only my dev server) a while ago. I thought everything was working again after some repairs, but recently noticed that cron on all my sites was giving me the 'Attempting to re-run......' message with last good cron log all corresponding to my permissions boo-boo date!

So - lessons learned:
1 - Check 5 times before running anything recursively!!!!!!!!
2 - Cron is sensitive to file/folder permission structure in sites/all/modules

I rebuilt my modules folder from fresh downloads (preserving the proper permissions) and was able to get cron running again following your instructions.

BIG thanks

WillGFP’s picture

WillGFP commented

For those attempting this on Drupal 7, I don't recommend deleting the "cron_key" row that comes up in step 2. If you're using crontab, deleting it can end up breaking cron.

gurtner’s picture

gurtner commented

I tried going into phpMyAdmin, then in the d_semaphore table, deleting the row name=cron. Then cleared all caches and ran cron manually. 2 seconds later, there was a new row with name=cron, just different value= and expire= values. There must be some other place that this cronjob still keeps running from...

danielgurtner.com

sarojbaniya’s picture

sarojbaniya commented

Thanks a lot. you saved me!

jorgeandrems’s picture

jorgeandrems commented

Thank you Jason! You saved me as well!

timmvt’s picture

timmvt commented

Using D7, I used
SELECT * FROM dr_variable WHERE name like "cron%"
and then disabled all non-core modules using
drush pml --no-core --type=module --status=enabled --pipe | xargs drush -y dis

Once re-enabling the modules, one by one, I was able to narrow down the offending module.

Thank you, Jason, and everyone else who provided assistance in this thread.

Cheers!

nlisgo’s picture

nlisgo commented

Not sure why this worked but none of the above did the trick for me. I was attempting to run elysia-cron using drush and I interrupted it (Ctrl-C) and then when I tried to run it again the terminal reported: WD cron: Attempting to re-run cron while it is already running.

I used the drush -v flag to see if I coul get more information and not the following step:

Executing: mysql --defaults-extra-file=/tmp/drush_AmiZ79 --database=elife_profile_test --host=localhost --silent < /tmp/drush_yvuWGB

I decided to look in the /tmp folder to see if any of these drush_* files were still there and there were 2. I deleted them and then the message went away.

rm /tmp/drush_*

hgoto’s picture

hgoto commented

To future readers using Drupal 7:

This thread is originally for Drupal 5.x. As many people said above, the approach for Drupal 7 is different. You should delete `cron` record in `semaphore` table to fix the error. You can do that in either way:

Drush:

$ drush eval "lock_release('cron')"

MySQL:

$ mysql -e "DELETE FROM semaphore WHERE name='cron';"

In the case of MySQL, please add your Drupal prefix to the table name if it's added.

- 7 - Cron stopped running; logs say: "Attempting to re-run cron while it is already running." - Drupal Answers

scottybrookie’s picture

scottybrookie commented

The drush version of this -- $ drush eval "lock_release('cron')" -- worked for me, after trying a number of other things that didn't work.  Thank you.

marco-s’s picture

marco-s
Location Switzerland🇨🇭
commented

This works for Drupal 8 too.
DELETE FROM semaphore WHERE name='cron';

ptocco’s picture

ptocco commented

I was unable to run cron, getting a white screen and log errors, etc. Then I installed https://www.drupal.org/project/cron_debug and in the admin/cron page, there was a new tab for Debug Cron. There was a list of modules and a Run Cron button. I ran cron and it reported which module was encountering errors. So on the same page I disabled the module and cron ran successfully. It was the Theme Developer module! I didn't have to mess with phpMyAdmin etc. Hope this helps somebody.

ProYoga.NL’s picture

ProYoga.NL commented

Thanks for the tip! On Drupal 7, and AdvAgg was the cause and Debug Cron helped me to identify it. Had to disable all related AdvAgg-modules listed under Modules, not only the one shown in Debug Cron.

Running the below in phpMyAdmin did not suffice.

DELETE FROM drup_semaphore WHERE name='cron';
sunnygambino’s picture

sunnygambino commented

If you are using memcache or Google pagespeed, don't forget to flush them as well!

drush cc all
echo 'flush_all' | nc localhost 11211
touch `grep "^ *ModPagespeedFileCachePath" /etc/apache2/mods-enabled/pagespeed.conf | awk ' { print $2; } ' | sed 's/"//g'`/cache.flush
rfmarcelino’s picture

rfmarcelino commented

For Drupal 9 and 10, the table is simply 'semaphore' so you would run:

DELETE FROM semaphore WHERE name='cron';
murz’s picture

murz
Primary language English
Location Yerevan, Armenia
commented

If you have Drush, you can do this directly from the terminal:

drush sqlq "DELETE FROM semaphore WHERE name='cron'"