I'm trying to run my cron manually by visiting mysite.com/cron.php

Normally when I do this (with other drupal sites of mine), I can access cron.php and once cron is run I see I blank page (mysite.com/cron.php). I then navigate back to my site by typing the site url into my browser.

What is happening here is I am going to mysite.com/cron.php and then after a few seconds being redirected to the page within my site that I accessed it from (say I typed in 'mysite.com/cron.php' while I had mysite.com/news loaded, I would be kicked back to mysite.com/news)

When I check the logs, I get the following message:

Cron run exceeded the time limit and was aborted.

Any ideas?

Using 5.1 on a site I upgraded from 4.7.3


VM’s picture

how much content is trying to be indexed ?

check your indexing throttle in administer -> search settings

try reducing the number of items indexed in a single cron run.

if that doesn't suffice try increasing max_execution_time in php.ini

bugmenot11’s picture

Type cron
Date Sunday, 4 March, 2007 - 15:41
User yassin
Location http://mysite.net/cron.php
Message Cron run exceeded the time limit and was aborted.
Severity warning

Durpal 5.1

Anyone know how to fix this?

VM’s picture

how much content is trying to be indexed ?

check your indexing throttle in administer -> search settings

try reducing the number of items indexed in a single cron run.

if that doesn't suffice try increasing max_execution_time in php.ini

baronmunchowsen’s picture

I resolved my issues by try reducing the number of items indexed in a single cron run (as was suggested below). Don't know if this is ideal, or really 'fixes the problem', but it suits me for my low-traffic site.

flanderz’s picture

I have had this problem several times and it ultimately was never related to the indexing. The most recent time I experienced this it turned out to be an error in my modules hook_cron code. I was trying to load a user with a null uid value. I'm too lazy to track this down in the source but I bet any type of runtime exception will generate this response. The execution time certainly had nothing to do with it in my case.

pjsz’s picture

Over two years later, you still get this message if you have an error in your hook_cron. Good to know. Thanks.

crystaldawn’s picture

Make that 3 years later. This error has absolutely NOTHING to do with time at all. You get this message when there is an ERROR in the cron pages.

nzcodarnoc’s picture

2012 and I've just discovered the same thing.

in php.ini

max_execution_time = 120

cron.php was failing almost immediately, there was no way it was maxing out the execution time.

I found my hook_cron error in the logs.

ablivio’s picture

I recently had the problems and finally discovered that I had a mis-configured input filter.

More specifically, some of my nodes had been created using the PEAR Wiki input filter. After a change of server (transfer of the site from one machine to another), the "Path of PEAR packages" setting in PEAR Wiki input filter configuration was incorrect, which led to a white page when trying to display the related nodes, and "Cron run exceeded the time limit" error when launching cron.

jurgenhaas’s picture

I'm hosting 10 similar sites on different topics. Setup and configuration for all of them is just the same. They all share most of the database tables.

The largest one is causing the above issue with the cron run and I suspect it's the xml sitemap update.

This site has almost 70.000 nodes, growing by another couple of thousands a day.

All other sites do work well and they are smaller (so far) - they will grow into this problem soon as well.

I have already reduced the chunk size of the sitemaps, but that doesn't help. I have also increased the execution time in php.ini and common.inc but it doesn't help.

Any ideas?

Have you seen the module DRD? A must-have for Drupal administrators.

liquidcms’s picture

I think there is a bigger issue here as is starting to be eluded to. I have a site i am just developing and i see this error about 70% of the time cron runs (once per hour). I have turned indexing to only 20 per run and this doesnt help - plus the white screen comes up in about 2-3 seconds.

so something (such as an error or something else that only seems to be hit when running cron) is causing the issue - perhaps various modules that don't do their cron correctly??

Peter Lindstrom
LiquidCMS - Content Management Solution Experts

liquidcms’s picture

to try to debug wehre cron is bailing, try this:

if you go into module.inc

and in the function module_invoke_all

add this extra line:

  foreach (module_implements($hook) as $module) {
    $function = $module .'_'. $hook;
    if ($hook == 'cron') watchdog('cron', "hit $module cron");   // add this line

You should be able to check out your watchdog log and see which module is killing cron.

jurgenhaas’s picture

It was the dba module and there was a patch available that writes database backup to the disk directly instead of collecting all in memory. I'm so glad this one is resolved now.

Have you seen the module DRD? A must-have for Drupal administrators.

pchammer’s picture

Great tool .
This was bugging me for a long time ,found my problem in the spam-module.

john ackers’s picture

I got a timeout as well after just 2 seconds but there was a "Call to undefined function" in the apache error log. Check your error log first!

jason.fisher’s picture

Updated Ubuntu and switched to APC. eAccelerator was still in my php.ini and causing cron issues.

error_log had:

eAccelerator requires Zend Engine API version 220051025.
The Zend Engine API version 220060519 which is installed, is newer.
Contact eAccelerator at http://eaccelerator.net for a later version of eAccelerator.

funana’s picture

Thank you for that hint. Found the problem. It was the pingback module in my case.

BarisW’s picture

Thanks funana,

it was the pingback for me as well that killed my cron. Will have to look how to get this module working without stopping the cron..

Baris Wanschers (@BarisW)
Drupal specialist

gausarts’s picture

Hi, Peter
I tried your code with drupal 6, and see my logs. The repetitive warnings always ends with this:

cron 09/25/2008 - 01:50 Cron run exceeded the time limit and was aborted.
cron 09/25/2008 - 01:50 hit search cron
cron 09/25/2008 - 01:50 hit node cron
cron 09/25/2008 - 01:50 hit filter cron
cron 09/25/2008 - 01:50 hit dblog cron

When I see the details for the first, it show:

Type cron
Date Thursday, September 25, 2008 - 01:50
User Admin
Location http://.../admin/reports/status/run-cron?destination=admin%2Fbuild%2Fmodules
Referrer http://.../admin/build/modules
Message Cron run exceeded the time limit and was aborted.
Severity warning

The rests show additional messages respectively:
Message hit search cron, hit node cron, etc

So which is the guilty? Thanks

love, light n laughter

gausarts’s picture

Nevermind. The guilty goes to me:) I screwed up somehow with the input formats. In my case, Status -> Fixed. Thanks

love, light n laughter

jonpdx’s picture

What import forms did you screw up? I had the same problem as you after installing that line of code.

gausarts’s picture

I gave extra allowed html into filtered html such as <embed>, then somehow it conflicted with video filter. I didn't recall the rest, sorry. But when I removed that extra tag, and also disabled search module for a moment, the cron went smoothly.

love, light n laughter

love, light n laughter

bunset’s picture

it worked for me perfectly.
I can see that subscriptions mail module was killing my cron process then I disabled it and it works fine.

jonwatson’s picture

This was very helpful, thanks. In my case it was the PHP_filter module that was causing cron to hang. Strangely, all I had to do was disable the filter module and re-enable it again and all way well.


dadderley’s picture

This error started happening when the site was 99 pecent done.
Then I moved the site over to the production server (completely different set up) where the error persisted.

I spent a couple of days searching for a solution and tried tweaks to the php and mysql configuration.

Then I read this thread.

I turned off search and sure enough search for some reason was making cron hang. So why is that? I wondered.

I turned search back on and disabled all of the search add-ons like the cck field and node indexer thinking that they might have been screwing it up. As it turned out this had no effect. Cron was still hanging.

So I tried your trick of temporarily turning off the PHP_filter module.
Bingo! Tried cron and it ran fine.
I turned it back on. Ran cron and sure enough it ran fine.

My question at this point is, is this documented anywhere?
This is a real problem and a big pain in the butt to diagnose and fix.

Anonymous’s picture

+1 to this. Turning off PHP filter, running cron and then turning it back on solved the problem.

Zero4ffect’s picture

Awesome thread. Even though the module name didn't help much, the thread did. Disabling and enabling the PHP Filter fixed my cron woes. Thank you very much!!

ShaneOnABike’s picture

This also worked for me! Now if I can figure out what page or change is actually causing the problem.

ta5ae’s picture


ta5ae’s picture

Disabling and re-enabling the PHP_filter worked for me. Thanks so much. Was using Drupal 6.22.

yxf9099’s picture

Thank you

As If’s picture

Thanks, Peter!

Interactive Worlds and Immersive Obsessions

snorkers’s picture

Had been tearing my hair out for a day on a D6 site as cron had died. Tried your core hack and found out it was the Twitter module; no problem with the module itself, it's just I found out that some network ****er has recently blocked access to twitter.com.

Anyway - I know it fills up Watchdog if left as is, but is there any reason why a variant of this little hack shouldn't be part of core? Alternatively, if some fiend in the world of Devel can add this as an option in the Developer modules, it would certainly be useful.

Thanks again @liquidcms. You've preserved my sanity for the weekend.

Michael Hofmockel’s picture

Thanks for the debugging cron code. I found this post in 2 minutes after noticing my problem. Another 2 minutes later problem solved.

bsuttis’s picture

Snippet's really helpful, thanks.

node.module appears to be my issue, I assume having 15000+ nodes in a Dreamhost Private Server environment is not an ideal situation, and I've found that commenting out node.module's cron hook lets cron run and complete.

My question is, looking at node.module's cron hook, is it really that important? From the limited reading I did, all it does is loop through each node and update it's read/new/updated tag that appears on admin/content/node. Are there other issues that would occur if I left it commented out for the time being? Other than the 'new' markers not working?

alexfisher’s picture

Many people out there are struggling with errors like:

include_once(modules/user/user.admin.inc) [function.include-once]: failed to open stream: No such file or directory in ... /theme.inc on line 283.

include_once() [function.include]: Failed opening 'modules/user/user.admin.inc' for inclusion (include_path='.:/usr/share/php') in theme.inc on line 283.

This crucial debugging step is what finally let me determine which module was screwing everything up. (It was the Search module for me, btw). Disabled and then UNINSTALLED that module and finally started working!!!

Big THANK YOU to Peter for this 2 year old piece of advice that paid off for a newly upgrade 6.14 site.

sridharpandu’s picture

As suggested by LiquidCMS I inserted the line in module.inc. Then ran cron, and viewed the recent log entries. The cron was aborting when it hit the XML sitemap. I went to the settings page of XMLSitemap and lowered the value of "Maximum number of sitemap links to process at once" from 100 to 10. Infact there is a hint by XMLsitemap to lower this value if there are problems in running cron!. I also changed the default base URL to include the "www" after http://, it has nothing to do with the problem but Google was ignoring the sitemap due to this. Then rebuilt the sitemap and ran cron again. It sailed through. Thanks LiquidCMS.

Best regards


Acer Aspire 5745
[i5 430M, 3GB, 320GB]
Ubuntu 12.04 (Precise Pangolin)
Drupal 6.15, 7.x
DigitalOcean, Go Daddy, Rackspace,

alotronic’s picture

Showed me something so totally obvious I should have seen it right away, needed the php4 date module - didn't see it as I ad moved site from my test to production. Switched on php4 date mod and all was fixed.

Brian Tastic’s picture

great little code snippet, it really helped me debug a few problem modules.

I hear that Drupal 7 will come with some checking service, that will test if modules are likely to break Drupal and will not be approve if this is going to be the case. Great.

amirtaiar’s picture

Every place I put this line I get error.
Can you help with where excactly should I put it?

Managing Partner - Reasonat Web & Digital development.

amirtaiar’s picture

I have sacseed with that but looking at my phpmyadmin I see no table named watchdog!

Managing Partner - Reasonat Web & Digital development.

kandalam’s picture

Thanks a lot....
after digging my head and scratching my head for 2 days I found this link....

My problem was with the update module. Just disabled it and got the things working...

pokepasa’s picture

Same here.

The problem for me was the UPDATE MODULE.

But now the problem is... how I can check for new updates? Every time I check manually for updates, I get out of memory...

VM’s picture

you have to increase memory on the server or most hosts: http://drupal.org/node/207036

Als’s picture

Adding my voice to confirm the usefulness of this single line of code.

kylealmas’s picture

This is a great debugging tool. I found my problem in Search where the index process was trying to index a page containing a redirect, causing cron to never finish.

HydroZ’s picture


thank you, saved me a lot of time finding out the reason, why cron was aborted due to timeout.

As mentioned above, cron gives the message "...exceeded..." when an PHP-Error occures.

liquidcms debugging method will help everybody to figure out, in which module the error occures.
Proceed to find within this module hook_cron() to start working on this issue.


sb56637’s picture

A million thanks to liquidcms for this, I found the problem with this.

mrtoner’s picture

Support Nag was the culprit.

Thomas Sewell’s picture

On the sitemap configuration page, turn off submitting your sitemap with every cron run.

Presumably the submission process is timing out.

If you really want that feature, test the urls contained in the setting manually for submission to see if they work as expected.

phpsharma’s picture

You can do

on top of cron.php

so that the script will run forever - however this is not recommended and your web server might catch you out with an imposed HTTP timeout (usually around 5 minutes).

ashish.cms’s picture

when I run the cron from browser like http://www.example.com/cron.php then cron runs successfully but if I sets cron from c panel cron jobs then its showing "Cron run exceeded the time limit and was aborted." error 80-90% times.
I am stuck on this problem.
I have used set_time_limit(0); at top of cron.php
reduced the number of items indexed in a single cron run to 10.
but all in vain any body have any idea about it ,why it is happening?

andrus_k’s picture

>>when I run the cron from browser like http://www.example.com/cron.php then cron runs successfully but if I sets cron from c panel cron jobs then its showing "Cron run exceeded the time limit and was aborted." error 80-90% times.

I have the same problem. Any ideas?

geerlingguy’s picture

Another 'me too' - don't know why this is happening. :-(

Personal site: www.jeffgeerling.com

deekayen’s picture

I have experienced this when I move modules to a different location that invoke cron. I try to run cron.php and it instantly stops. Just re-save the modules page and it'll reset the saved location of the modules and cron runs again.

parrottvision’s picture

I am running Drupal 6 and this happens. If I disable the search module it doesn't. But I can't really live with the search module off. I haven't found a fix yet, open for ideas.

UPDATE: FIXED! After alot more searching I found the issue was with a node that I had PHP in that said "If the URL is missing a variable then redirect to homepage" (using PHP header: location) - So when cron was running through search indexing it was hitting the page and then redirecting to the home page. This is a bad piece of code and silly of me. I removed it - job done.

This node solved it for me. http://drupal.org/node/102138

aymeric’s picture


We solved our cron problem like you: removing a php header location in one Node. Thank you for your message! it's works fine now :-)

boclodoa’s picture

Same problem, the code on my node was

global $user;

Thanks a lot :)

- update -

solved with

if($_SERVER['SCRIPT_NAME'] != '/cron.php'){ ...

thanks to http://drupal.org/node/102138#comment-476860

kaptain_kyle’s picture

After checking watchdog it appears that I haven't completed a single cron job successfully for quite a while on my 5x installation. I've modified module.inc file show each module.

My last entry before it times out is... hit search_block cron (aka Restricted Search)

When I run cron manually it waits and eventually takes me to my Gallery page (Gallery2 with gallery.module) and throws the same exception in watchdog.

If I turn off the search_block module the cron job will complete (hooray!). Unfortunately turning this module off permanently is not really an option. Currently PHP is configured to max_execution_time of 60. What am I missing?

mroswell’s picture

How did you modify module.inc to show each module? I'm having the same kinds of cron trouble (in 5.x) , and would appreciate the troubleshooting tip.

UPDATE: I see it here: http://drupal.org/node/123269#comment-644012

mroswell’s picture

Adding the module name to the log worked (API's module is where it stopped).

Does anyone know how to log a system message to add the particular offending file that causes the thing to stop? (not just the module?) I'm in Drupal 5.

webfootwander’s picture

Disabling the PHP filter, running cron from mysite.com/cron.php and then re-enabling the filter worked fine. Seems a bit bizarre to me. That bit of code in modules.inc really works! Thanks heaps.

slinberg’s picture

That worked for me too, in the end... disabling the PHP filter (which is dangerous for my site), re-indexing or running cron, and then turning it back on.

However, this is not a workable ongoing solution; cron needs to run without dying on the PHP filter. What needs to be done here?

mgroo’s picture

Great. Disabling the PHP filter did work for me as wel.. I wonder why that is. After enabling the PHP filter, CRON was still running without any problem

geerlingguy’s picture

I'm having trouble from time to time with this... still trying to figure it out. But it often boots me to a 500.shtml page after the cron runs complete. Very odd behavior indeed.

Personal site: www.jeffgeerling.com

raintonr’s picture

Be careful of using drupal_goto in your php_filter nodes. See #453286: drupal_goto breaks cron.php

geerlingguy’s picture

This is something really odd. First off, cron always hits the search module and grinds to a halt.

But that's not the weirdest thing; if my crontab entry hits cron (using the wget method), cron times out after two or three times (I have it hit every half hour). But if I manually start cron using the 'Run cron' task in Administrator Menu, cron runs without a hitch. What could be the difference there?

Personal site: www.jeffgeerling.com

geerlingguy’s picture

I found and applied this patch #312390: Performance: search_update_totals() slow with large number of nodes (in comment #10) to Drupal 6.13's search.module, and cron times have decreased from ~8 seconds to ~1 second, on average.

Personal site: www.jeffgeerling.com

GBain22’s picture

Disabled the php input filter - kind of a nightmare if you have a large sites with plenty of modules - thanks for the help anyway guys.


tinem’s picture

I have tried putting this code if ($hook == 'cron') watchdog('cron', "hit $module cron"); // add this line in module.inc but what next? What is Watchdog log?

I also have some node where I use php and redirect but it can't be true that you can't use php code in Drupal, right? And it has been working before but not for a week and 3 days now. When I try to opdate cron manually I get one of the note sites where php is made from an external database.

On my host I have max_execution_time 300 but that is ok, right?

I use Drupal 6.11 and the site is here http://www.tinemuller.dk/drupal/. It's only a testsite but I'm still learning and would like to have this problem solved, please.

tinem’s picture

I have now deleted the site with the php code which I got to when running cron manually but NOW I get a message Page not found http://www.tinemuller.dk/drupal/node/721 - what does all this mean, please help?

I still have some more sites with php code from external database but will not delete them before I hear something from you.

tinem’s picture

I found this site http://drupal.org/handbook/modules/dblog/ explaining that in 5.x and earlier Dblog was called watchdog. So for beginners who doesn't know this - watchdog is Dblog. :-)

Now in my admin menu under Reports I see:
Recent log entries

Where do I go from here? If I take a PrintScreen of some of the Reports can someone help me further or tell me where to ask for help if not here, please?

liquidcms’s picture

@tinem - go to http://www.tinemuller.dk/drupal/admin/reports/dblog and select filter by "cron" at the top. If "cron" isn't in the list then that means you have no cron logs; if thats the case then it means you aren't running cron, if you do have cron msgs and you added my hack above.. the last one that shows should point to the module that is dying during your cron run.

tinem’s picture

@liquidcms - thanks for trying to figure out what went wrong. I have now uploaded a PrintScreen http://www.tinemuller.dk/drupal/div/dblog.gif which shows what I see but can't see any module mentioned or?

liquidcms’s picture

cron dies during search.. go to admin/settings/search and reduce number of items to index during cron run.

scifisi’s picture

admin/settings/search and I reduced the number of search items to index per cron run from 100 to 10 - now cron.php runs perfectly - really happy now :)

garyalldredge’s picture

You could just go to
when you do that it automaticly invokes cron and you can see the problem there.
Myne looks like this

Fatal error: Call to undefined function curl_init() in /usr/share/drupal6/modules/storage_api/storage_api.module on line 1244

so it looks like it is the storage api module that is giving me issues and not the time that it takes the scrypt to run

Thanks All and happy Drupaling

huc’s picture

All of this discussion was helpful in my isolating the same problem for site. The fix however was different:

In my case I isolated the error to the Aggregator module; the cron time out error was occurring because an off site RSS feed was out of date. Deleting the outdated feed corrected the problem and cron now runs normally with Drupal 5.19

zzrwood’s picture

I had the same problem when I moved a site from my VPS server to a shared hosting server. Cron ran fine on the VPS but not with the identical site on the shared hosting.

Eventually I found that I needed to disable the PHP filter module, run cron (which then worked), and then re-enable the module - cron then continued to work.

Hope this might help someone else - took me a fair bit of trial and error to get it fixed.


Robert in Oz

duckzland’s picture

+1 This solves the problem in my client site

if you can use drupal why use others?

anonymous07’s picture

One of numerous challenges and tweaks necessary for a D5 -> D6 upgrade :-(

I like that this did not involve having to hack/customize code. :-)

As If’s picture

Cron is really busy, even if items to be indexed is low, there are still lots of other things cron does (could be quite a lot, depending on which contrib modules you have installed). I have been experimenting with replacements for cron allowing better control of these individual tasks. The Supercron module is good. The Elysia Cron module is even better IMHO, but it is a little trickier to set up (you need to understand the syntax of a crontab). With these modules you can break up the various cron-driven tasks and have them run at different intervals.

Interactive Worlds and Immersive Obsessions

jmbailey’s picture

Just wanted to say that this had been a problem for me for a while and reducing the number of items to index worked for me.

strgpune’s picture

I had exactly same problem.

I installed "SuperCron" which helped me drill down all the installed modules. I noticed that "Notification" module is the problem. I disabled the cron job for it and the cron run after a long time!!!

I am now figuring out what to do with Notification module.

As If’s picture

If you use Elysia cron you can actually set the interval for each module's cron job separately. So you could make Notification run only once a day at your minimal traffic hour, or whatever. I've got some modules that only need running once a month, and others that need running several times a day. Elysia lets you do that.

Interactive Worlds and Immersive Obsessions

tusharb’s picture

Hi All,

New in Drupal World, and having some problem for running cron.php.
Cron.php works fine when search module is disable but once i enable a search module and went for re-indexing it shows 0% indexing.
After that i try to run cron.php and showing "Error. class 'tabs' not found and problem with line number 23 in the fie common.inc"[search moduleis enable in this case].

watchdog details after running search re-indexing

Type php
Date Thursday, January 14, 2010 - 18:34
User Admin
Message mysql_fetch_row(): supplied argument is not a valid MySQL result resource in C:\Program Files\Apache Software Foundation\Apache2.2\htdocs\drupal_dev\includes\common.inc(1645) : eval()'d code on line 22.
Severity error

watchdog details after running cron.php and search enable

Type php
Date Thursday, January 14, 2010 - 18:13
User Admin
Message mysql_fetch_row(): supplied argument is not a valid MySQL result resource in C:\Program Files\Apache Software Foundation\Apache2.2\htdocs\drupal_dev\includes\common.inc(1645) : eval()'d code on line 23.
Severity error

I want search module along with cron.php. Thanks in advanced.

canyonbreeze’s picture

I was having the same issue and went through all the comments on this page.
- Adding the debug code showed that cron died at the search module.
- Disabling then re-enabling the php input filter fixed the problem.
- A node that used drupal_goto in the php broke it again.
= Replaced occurrences of drupal_goto with the depreciated meta http-equiv="refresh" content=... and it works now.

Obvious conclusion: drupal_goto is defective.

As If’s picture

That's this issue here

Interactive Worlds and Immersive Obsessions

mstrelan’s picture

I have drupal_goto in a form alter for a webform and it caused this problem when the node was being indexed. The workaround I'm using is this

if ($_SERVER['SCRIPT_NAME'] != '/cron.php') {
danrwhit’s picture

Had the same problem and just solved it. What did it for me was a setting in the Suhosin.ini file (a PHP security utility). I had this setting enabled:

suhosin.executor.disable_emodifier = On

Which disables the use of preg_replace with the /e modifier. Drupal's cron.php uses preg_replace with the /e modifier, so I had essentially disabled cron.php from running.

Changing the setting to 'Off' and restarting Apache was all that I needed.

rmontero’s picture

I am having that exact same problem.

The site I'm working on had some very bad PHP logic and drupal_goto() calls in the nodes and panel pages.

I will post my solution when I find it.

- Rob -

Best regards,

Rob Montero

r.aubin’s picture

Another vote for SuperCron. It allowed me to quickly figure out where the hang up was so I didn't waste any more time looking through log files for something that wasn't being logged.


amysteen’s picture

I got this error as well. I limited the amount of nodes in my xml sitemap and that solved the problem.

ptoly’s picture

Same problem here on 3 of my sites. Even if the site is lean (only 19 records to index) the search module stops cron. PHP snippets are not my problem. Shut them off and the problem continues.

If I reinstall the search module using Devel I get to a certain point (7 records left to index) and the cron fails. This seems to indicate that there is more problems with the search module than drupal_goto().

Does anyone have an idea how to figure out which record, during the search index, is throwing the wrench in the works?

Continuing to sleuth...

VM’s picture

one way would be to clear the index and see if it dies at the same node.

ptoly’s picture

Okay, I've figured out my problem - it is the testimonial module, which uses drupal_goto() in the testimonial_nodeapi function. Issue noted here http://drupal.org/node/518668.

There are two fixes: 1. Shut off the testimonial module, as you only really use it to install a prefab content type with a view. Testimonials work just fine with it off (though you'll loose the formatting).

Or 2. change line 46 of the testimonial.module file from

if ($node->type == 'testimonial') {


      if ($node->type == 'testimonial' && $_SERVER['REQUEST_URI'] != '/admin/reports/status/run-cron') {

There is clearly another factor or factors involved as the Testimonial's module does not always stop cron. I actually shut off testimonials, ran cron (just fine), then turned

Sleuthingwise, the answer was staring at me in the face the whole time as the cron run would halt at the Testimonial's views page.

The debugging code @liquidcms gave me was useful. It did tell me that cron stopped at the search module. However the search module actually runs other module's scripts during cron and that is why the best hint was the page that I actually landed at, when cron died.

Hopefully this will help others.

I see from a Google of 'drupal_goto() cron' that this has been an issue since 2006!

tallsimon’s picture

In case anyone else has this with messaging and notifications-

I was running 100 rows for search, 100 rows for sitemap and messaging and notifications system. I had over 3000 notifications waiting to be sent. the combination wass too much. Cleared the messaging queue and reduced cron runs for xml and search, sorted! thanks for all tips above.

copeasetic’s picture

My solution to this issue was to change my send interval to immediately and changed the global notifications from content type to Global. I have a small site, so immediate works for me.

Hope this helps someone else.

jelo’s picture

I just ran into the same problem with notifications in an Open Atrium installation. As soon as 1 item is in the notifications queue, it kills cron. Once I clear the queue, I can execute cron, but still get an error in the log:

Reached processing limit on queue processing

Not sure why this happens... Any solutions?


hartogsmith’s picture

was a misconfigured (by me) auto-backup in backup/migrate in my case

snippet helped identify issue in seconds (see comment above: http://drupal.org/node/123269#comment-644012)


Sam Moore’s picture

Same for me - I migrated my whole server, and had left some Destinations defined in Backup and Migrate, which no longer existed.
Deleting these allowed Cron to run.
I'd never have found this without the addition of
if ($hook == 'cron') watchdog('cron', "hit $module cron"); // add this line
to module,inc as recommended above.
So many thanks to liquidcms!!

Gabriel R.’s picture

After days of hair pulling (the watchdog didn't work for us) I discovered it was the Search index.

Clearing the search index unstuck the cron.

caspercash’s picture

thank you very much for this solution! http://drupal.org/node/123269#comment-4135096 i've been searching for months now and poof! thanks to this thread! more power to drupal!

nathan573’s picture

After upgrading a site from 5 to 6 I found that when running cron manually to make the Search module index nodes, it was stopping short and giving a watchdog error "Cron run exceeded the time limit and was aborted.". I tracked down the offending node by modifying the node_update_index function in node.module thusly:

  while ($node = db_fetch_object($result)) {
    watchdog('cron', "node_update_index: nid:".$node->nid." ".l("edit node", 'node/'.$node->nid.'/edit'));   // add this line **************

After running cron, when I checked the logs I found a node that had some PHP in it that was breaking since it was calling form_render.

mejpark’s picture

Disabling PHP Filter module solved cron problem for me. It also works as normal after re-enabling PHP Filter. Bizarre!

WeRockYourWeb.com’s picture

Drupal 6.x, disabling and re-enabling the "php filter" module worked here as well.

kusang’s picture

it take me 1 week to solve this problem!!! Thanks!

MattMoody’s picture

Drupal 6.22
Problem was in luceneapi/lib/Zend/Search/Lucence/Index/SegmentMerger.php

while (($segmentInfo = $segmentInfoQueue->pop()) !== null) { 
            // Merge positions array
            $termDocs += $segmentInfo->currentTermPositions();

            if ($segmentInfoQueue->top() === null ||
                $segmentInfoQueue->top()->currentTerm()->key() !=
                            $segmentInfo->currentTerm()->key()) {
                // We got new term
                ksort($termDocs, SORT_NUMERIC);

                // Add term if it's contained in any document
                if (count($termDocs) > 0) {
                    $this->_writer->addTerm($segmentInfo->currentTerm(), $termDocs);
                $termDocs = array();

            // check, if segment dictionary is finished
            if ($segmentInfo->currentTerm() !== null) { 
              $varing = $segmentInfo->currentTerm();
              //cron non stop watchdog('cron_luceneapi', $varing->field . ' ' . $varing->text);
                // Put segment back into the priority queue

cron was never go out of this cycle
Whant I do:
1. comment $segmentInfoQueue->put($segmentInfo);
2. run cron
3. uncomment $segmentInfoQueue->put($segmentInfo);

after that run cron 5 or 6 times - all works. I hope it not a temporary fix and cron will work fine.

openthinktech’s picture

@As If

I installed the Elysia Cron module and ran each cron job separately to find out that it was the emf_cron job that failed. After running it once and it failing, then I could click Run cron from within Elysia. After that I can run cron normally from Status Report and Poormanscron (every 3 hours).

I'm thinking that I had too many logs in the emf_cron job?

Thank you so much for your suggestion. I tried all other suggestions on this page.

Drupal 6.22


Thomas Newman
Web Developer

chris_car’s picture

Running Drupal 6.x, disabling and re-enabling the "php filter" module worked for me as well.

mejpark’s picture

+1 for disabling php filter - this worked for me, but ultimately the problem was caused by an illegal mix of collations error.

masher’s picture

Yep, same here, disabled and enabling the PHP filter module allowed cron to run.

Thanks to all above

millionleaves’s picture

I have a site where this had worked fine for two years then suddenly started causing the cron issue. I could still run a manual backup, but not a scheduled backup.

After much digging and experimenting with destinations and schedules in the Backup and Migrate module settings, I simply disabled, uninstalled then reinstalled the module. I then configured it exactly as it had been before and everything worked (and no more cron crashes).

Hope that helps someone. An easy fix to try in most cases!

I provide Drupal, Drupal Commerce and CiviCRM development services for customers in New Zealand and beyond

tran_tien’s picture

Thank man, it module Backup and Migrate cause

Graham Leach’s picture


The module that was killing my cron job run was Browscap. Here's some related information

Browscap 6.x-2.1 Provides a replacement for PHPs get_browser() function.
Required by: Mobile Switch (disabled)

I also implemented the code a bit differently. Here's how I did it, mostly to make it more readable for me

foreach (module_implements($hook) as $module) {

# GL 2016-10-17
# Troubleshooting line to figure out why cron is crashing
if ($hook == 'cron') watchdog('cron', "cron now processing: $module");


Graham Leach