Run cron manually in the status report page, I get message "Cron run failed". Go to reports -> recent log messages, I can see a lot of repeated messages below in every minute for type cron:

    Attempting to re-run cron while it is already running.
    Attempting to re-run cron while it is already running.
    Attempting to re-run cron while it is already running.
    ...
    ...

Any help? Thanks!

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

maxoskar’s picture

Have the same problem and google found me these pages:
http://success.grownupgeek.com/index.php/2011/02/12/drupal-fix-cron-alre...
http://drupal.org/node/360836

Flushing my caches didn't work for me so I will have a look at the second link.

astra’s picture

For me it doesn't work either to just clean caches.

Hi maxoskar, did you try that way from your second link?

astra’s picture

Fixed the Cron problem for my site:

1. Open up my PHPMyAdmin and go to the table variable

2. Click on SQL and run this command:
SELECT * FROM from variable WHERE name like "cron%";

3. I can see 3 variables with "cron" and delete all of them:
delete cron_key
delete cron_last
delete cron_safe_threshold

4. Go to Administer > Modules and disable the module Backup and Migrate (For my situation there are some error massages from this module, I try disable it to see what happened. Maybe this step is not neccesary)

5. Go to STATUS REPORT and click on RUN CRON MANUALLY

6. Go to Recent log message and can see the massage: Cron run completed.

7. Enable the module Backup and Migrate (disabled in the step 4, maybe just step 1, 2, 3 and 5 can fix this problem)

Now the cron problem is resolved.

hunsmirefm’s picture

Version: 7.7 » 7.8

I've been experiencing this problem for the past two weeks running 7.8.

So far I've deleted

delete cron_key
delete cron_last

from the mysql database.

I disabled all of the modules, cleared caches a few times; cron is still failing.

I've now disabled most of the core mods except for the ones logging errors, cleared caches again, and cron is still failing.

I've basically hit the wall and run out of my limited technical skills/knowledge. Thanks for providing any help!

janucen’s picture

Version: 7.8 » 7.12
Issue tags: +Attempting to re-run cron while it is already running, +Search module re-indexing 0% of 100%, +indexing failed, +indexing 0%

Hi, in my case the issue was missing php.ini file on my web let say "http://www.example.com/". I am running 7.12 version with many modules. My provider (Greengeeks.com) however does not automatically support PDO which caused PDO error message (without this code):
extension=pdo.so
extension=pdo_sqlite.so
extension=sqlite.so
extension=pdo_mysql.so

If anyone would like to try to solve this problem the way I had, do this:
1. Open your Cpanel
2. Go to your "http://www.example.com/" - in Cpanel you should open - /public_html/example.com
3. From Cpanel click "New File" - left corner in my Cpanel - write "php.ini" - OK
4. Find this file and Code Edit it. (left button click at php.ini to mark it, than left click button offers btw the code edit which is going to open in a new tab).
5. Copy and paste the above 4 line code and save it. Additionally, you can tweek the php.ini - find useful information here - http://drupal.org/node/207036
6. Clear all caches.
7. Clear your browser caches - sometime could also help.
8. Run Cron.

I am sorry if this did not help. In that case just delete the php.ini file and try to find some other answers.
Good luck.

rickmanelius’s picture

I had a similar problem on Drupal 7.12... and I had to keep removing the cron entry in the semaphore table and just rerun over and over until finally it went through and I haven't had an issue sense.

Jooblay.net’s picture

We have had this issue at times: "Cron run fails"

To reproduce: In our case this has occurred when we take our site from LAMP^ (Linux Apache2 MySQL PHP Hypertext Preprocessor) onto a production server hosting account. If we use the backup migrate module database .mysql files compressed or uncompressed and then import them into our phpmyadmin on the production site we get the fail. We have played with the import settings and no luck.

Solution: How we have fixed this is take the actual database in phpmyadmin and physically export it and then import it onto our production server. This file on direct export from LAMP^ (Linux Apache2 MySQL PHP Hypertext Preprocessor) phpmyadmin is .sql Then importing that to our phpmyadmin production server cron works great.

Conclusion: It seems that this ultimately could be caused from corrupted or mis-configured databases. At this time it seems the databases backed up in the Backup & Migrate module LAMP^ (Linux Apache2 MySQL PHP Hypertext Preprocessor) are totally corrupted as a result. So when you think you have a sound backup you really may not.

This may help out:)

Jooblay.net’s picture

This sounds like a corrupted database? Where are you pulling your databases from when you upload them into phpmyadmin? Maybe try checking the quality of your database, in our cases when we have ran across this it seems to be the database format. .sql import now .mysql but then again there are a lot of settings/

hope this helps:)

danielgmc’s picture

The cron lock is held in the semaphore table. This SQL command can help you check for the lock:

SELECT * FROM semaphore WHERE name = 'cron';

Reg’s picture

Version: 7.12 » 7.15
Category: support » bug

I'm changing this to a bug report because I see an error in the code (someone who knows it better might prove me wrong).

I've been looking at this with the latest Drupal (7.15) and it seems there is some legacy code that needs to be removed or updated. In drupal_cron_run() you get this:

drupal_register_shutdown_function('drupal_cron_cleanup')

.
If you look at drupal_cron_cleanup() you see this code:

  if (variable_get('cron_semaphore', FALSE)) {
    watchdog('cron', 'Cron run exceeded the time limit and was aborted.', array(), WATCHDOG_WARNING);

    // Release cron semaphore.
    variable_del('cron_semaphore');
  }

The problem is that as far as I can see drupal_cron_cleanup() this is the only routine that uses 'cron_semaphore' from the variable table, which is a Drupal 6 methodology. It should now probably be something like:

if (!lock_may_be_available('cron')) {
    watchdog('cron', 'Cron run exceeded the time limit and was aborted.', array(), WATCHDOG_WARNING);

    // Release cron semaphore.
    lock_release('cron');
  }

However, if you look at code in lock.inc there's quite a bit of code to handle timing on locks already so it may not even be necessary at all any more (someone who knows those parts of the system better could answer that.)

Reg’s picture

Here's a patch against 7.15 for what I mentioned in #10. Use with "extreme caution", this is a ~ best guess~ on what the code should be base on a quick look through it. It really needs a core developer to take a closer look.

Reg’s picture

Nothing functionally different, just had a duplicate comment in the last patch.

Jooblay.net’s picture

Can anyone reproduce these symptoms before we start patching... We have never ran across this error with a healthy database:) I am suspect of this actually being anything more then corruption of the database?

The fact that this is not a very active issue may indicate the this fact as well? Not sure:)

Did you check for the corruption in your database by using a healthy backup?
Hope this help:)

Reg’s picture

Hi Leseen,

I never had those symptoms instead I came across this issue from looking at the code and then looking for any issues that might relate to what I saw. And, that was that the code makes no sense.

If you have any background in this part of drupal or are just another developer like myself I would really appreciate you looking at what I found -- and it's really simple.

In drupal_cron_cleanup() there is use of 'cron_semaphore' in the variable table and a search through all the code using my IDE shows no reference from any other function anywhere in Drupal using this variable. In other words -- it's totally useless code.

However, a lock for the cron IS obtained in drupal_cron_run() through the lock_aquire() and released through lock_release() -- a completely different methodology.

I believe this is going to require someone looking through the code and verifying my findings because waiting for symptoms to to show this finding may never happen because the functions in lock.inc have their own time limit code so even though the code in drupal_cron_cleanup() looks useless it may actually never be needed except under weird circumstances.

One example I could think where it might be useful is if Drupal crashed in the middle of a cron run because of bad code in a add-in module but then you are relying on one problem to surface to find another which is not a great way to go.

They are both really short functions and would take but a moment to look at and compare. Here they are:
http://api.drupal.org/api/drupal/includes!common.inc/function/drupal_cron_cleanup/7
http://api.drupal.org/api/drupal/includes!common.inc/function/drupal_cron_run/7

Anyway, I hope you can take a quick look at let me know if you agree or not with what I have found.

Jooblay.net’s picture

Reg:) i would say this is a totally different issue all together... Checked the code and you could well be onto something:) Can we move this to another issue queue? Do you think this is causing the above issue? "Cron run fails"?

Great work by the way... Power To The DRUPAL

Will.Power on drupal community:)

Reg’s picture

Hi Leseen,

I agree that it could be separate issue and feel free to move it but I ~suspect~ that under some circumstances it is the cause of this issue so if you want to separate it out I think a link back to this issue and vice versa would be appropriate.

Thanks for the note!

BTW, I changed my installation to use the patch above, no problems so far and that's with a multi-site install.

Reg’s picture

I created a separate issue for it here:

http://drupal.org/node/1777162

Jooblay.net’s picture

On "Attempting to re-run cron while it is already running."

Do you have the Backup & Migrate module loaded on your site?

shortspoken’s picture

Installing the module http://drupal.org/project/cron_debug did the trick for me as I had the same problem not being abled to run the cron, even with Backup & Migrate enabled... Thanks to jacobpov in this Issue.

Jooblay.net’s picture

"Cron run fails" enabling modules.
cron runs fail possibly do to allowing to many functions timed to run. xml sitemaps, search and more. limit these to the smallest possible queues and test. This issue most likely is the cause of the cron run failing upon installing or enabling a new module.

this only seems to be an issue for sites with 5k or more pages in content?

Reg’s picture

@leseen have you defined what is really going on? I ask because usually if a task is going to take too long on a cron run it just stops at a certain point and starts up where it left off on the next cron run.

Do you have an exact error message? I've never heard of enabling modules during a cron run. Recently I had to up my memory limit because enabling modules was the one action that would max out my PHP memory limit.

Jooblay.net’s picture

Hey Reg,
As far as we can tell at this time, cron runs fail when assigned to many tasks in indexing while cron is being run. By increasing pages to be indexed via search, xml sitemap, backup_migrate and other modules.

Everything is cleared up by limiting these tasks to the absolute minimal.

Sorry Reg i have not had time to look at the code your setup in the above comments.

Thanks to everyone in the community for so much love and support... Power to drupal:)

Reg’s picture

@leseen: Without actually looking at your system I would tail your PHP error log file and see if your getting out of memory errors. These errors (and a few others) won't show up in your Drupal log because it crashes the code before Drupal fully loads so Drupal never gets to run.

Jooblay.net’s picture

thanks for the tip will check it out... and post back:)
thanks again:)

Version: 7.15 » 7.x-dev

Core issues are now filed against the dev versions where changes will be made. Document the specific release you are using in your issue comment. More information about choosing a version.

poker10’s picture

Issue summary: View changes
Status: Active » Closed (outdated)
Issue tags: -Attempting to re-run cron while it is already running, -Search module re-indexing 0% of 100%, -indexing failed, -indexing 0%

The drupal_cron_cleanup() is now deprecated and not used anywhere, so patches here are not relevant anymore. See: #1775488: drupal_cron_cleanup is not converted to lock.

If someone experience Attempting to re-run cron while it is already running., it means that the cron is still running (there could be some long running tasks like indexing, sitemap generation, ...). This is not a problem, it is a correct behavior of cron locking.

ohanm’s picture

@poker10,
Can you clarify something please? Will the warning "Attempting to re-run cron while it is already running" be displayed even if cron takes less than 240 seconds (default) ? My cron always completes normally, and rarely takes more than 60 seconds, but I still occasionally see the warning. This behavior started after I migrated to a new server and moved from mysql 5.6 to msql 8.0. Thank you in advance.

poker10’s picture

@ohanm it depends on the cron settings, see: https://www.drupal.org/docs/7/setting-up-cron/overview. If you have set-up your cron in Drupal, so the field "Run cron every" is set to something different from "Never", then the cron is being checked and run on each user request. So when one user triggers the cron, other user accessing the site in the same time (while it is still running) will trigger that warning. It is better to set the cron to run directly from an external trigger (for example from webhost directly accessing the cron.php link). Then it will not run on user requests and no warning would be logged. See: https://www.drupal.org/docs/7/setting-up-cron/overview#s-disabling-autom...

ohanm’s picture

@poker10,
Thank you for the perfect explanation, there is so much miss-information about this topic! It was set to every 1-hour. I've created an external cron task and no more warnings.