I got the dreaded "Cron run exceeded the time limit and was aborted." message...can't remember if there was a parameter that can be set to make it go away. Cron does run to the end of invoked manually.

Comments

raychaser’s picture

I've got the same problem "Cron run exceeded the time limit and was aborted."

I can't find anything in the logs.... either that or Lunarpages cpanel is lying to me that there aren't any errors.

tried:

  1. Indexing limit is at 10 nodes per cron run
  2. Tried disabling modules one at a time. Disabling Search fixes it but we kind of knew that already
  3. I've traced it to when cron does the indexing and trips module_invoke() with the 'node' module

I'd be willing to bet this is due to some bad content or PHP content choking up my site

Also cron dumps me into /user/1/edit before dying which is weird....

Question: How do I find the problem here? Is there a way to enable more explicit logging other than dropping watchdog statements everywhere?

raychaser’s picture

Well I learned something today.

I finally traced the problem to a bad node PHP content that was causing a feedback loop

Here's how I got there:
in search.module in the function search_cron()
I dropped in a line:
if ($hook == 'cron') watchdog('cron', "hit $module cron");
Which told me (by going to the watchdog logs) that it was the 'node' module and the 'update_index' hook causing the problem

Then inside the node.module I looked at node_update_index()
and I was able to drop a line to print out the $node->nid

Phew. And all because of 2 lines of bad PHP.

I kind of wish there was some way Drupal could just have told me "Node with nid=4 is stupid. Fix it!!!". Oh well. All part of the learning process.

Dinis’s picture

Cheers for posting your solution, it helped me fix exactly the same issue :)

stevestaso’s picture

Thanks raychaser42
Here is a few more details on where to place the temporary debug code:

In search.module:
After these 2 lines:
// Update word index
foreach (module_list() as $module) {
Add this:
if ($hook = 'cron') watchdog('cron', "hit $module cron");

In the Recent Log Entries, you'll see the various modules listed, but the last module (top of the list) is the one causing the problem.

If it was the node module,
Then
In node.module:
After this line:
while ($node = db_fetch_object($result)) {
Add this:
watchdog('cron', "hit $node->nid");

In the Recent Log Entries, you'll see the various nodes listed that Search tried to index, but the last node (top of the list) is the one causing the problem.

Delete it.

:)

alextronic’s picture

thank you SO much.

furvus’s picture

I had the same problem and finally the problem was

the

drupal_goto($url);

function...

for some reason when the node_update_index() reads the node with 'drupal_goto' the cron page was redirected to the goto $url ...

kind regards

JThan’s picture

This was very helpfull. Thank you.
@ll: Remember to not put drupal_goto into a php node without checking if it is the cronjob coming by.

501cGeek’s picture

Thanks for the tip! This was my problem, too.

From another site, here's some PHP you can use to make sure cron.php doesn't follow your drupal_goto redirect.

if ($_SERVER['SCRIPT_NAME'] != '/cron.php') {
       drupal_goto('someplace/in/your/website');
}

(found at http://www.usefulsuspects.com/2010/01/solution-for-cron-and-drupal_goto-...)

srini85’s picture

that is great work! It solved my problem! Only thing is that I had to enter

watchdog('cron', "hit $node->nid");

after every
while ($node = db_fetch_object($result)) {

there are 4 different locations of this.

Also I found that the node was not displaying so I had to goto the edit page through the browser, then delete it.
E.g. node 92 was the problem so I had to type in

www.example.com/node/92/edit

then remove the node.

RacerFx’s picture

I found if i uninstalled this module it worked for me,
Notify 5.x-1.1 Enables notifications of new content and comments by e-mail.

Thanks for the help in finding the problem

timingalls’s picture

I had installed a module which provided for filtering of Wikimedia tags when I converted from a Wikimedia site to Drupal. One of those filter modules needed a specific PEAR module for PHP, and I somehow deleted it from my site. The solution outlined by Raychaser42, stevestaso, and srini85 worked. I had to paste the fix in 4 times, just like stevestaso mentioned.

I didn't need to delete any nodes. I just had to switch the input filter on each node to the main one I use. Deleting the bad input filter automatically switched any nodes using it to the default input filter.

While diagnosing the problem, I found that when I deactivated the Search module, the cron job completed. The search index was not being rebuilt. Now the search index gets rebuilt just fine.

I also was getting blank pages if I searched for a keyword that was contained in one of the bad nodes. So this also solved my problem of getting the White Screen of Death (WSOD) during searches. Now those nodes get indexed and show up on results.

skclewis’s picture

I had the same problem. I found this thread among many others talking about adding code, etc. However I found this site: http://www.mojahmedia.net/drupal-cron-run-failed-cron-busy-probably-stuc... and followed the suggestions and cron worked. I had the subscription module enabled which I disabled. I also reduced the index per cron run to 10. After that cron ran fine.