Hi,
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
Comments
=-=
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
I am having the same problem
LOG:
Type cron
Date Sunday, 4 March, 2007 - 15:41
User yassin
Location http://mysite.net/cron.php
Referrer
Message Cron run exceeded the time limit and was aborted.
Severity warning
Hostname 91.153.141.155
Durpal 5.1
--
Anyone know how to fix this?
=-=
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
I resolved my issues by try
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.
Not necessarily the indexing
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.
Still the case in 2010
Over two years later, you still get this message if you have an error in your hook_cron. Good to know. Thanks.
Make that 3 years later.
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.
2012 and I've just discovered
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.
Check input filters
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.
Same problem, it seems to be the sitemap module
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?
bigger issue
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
Peter Lindstrom
LiquidCMS - Content Solution Experts
try this to debug
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:
You should be able to check out your watchdog log and see which module is killing cron.
Peter Lindstrom
LiquidCMS - Content Solution Experts
Found it
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.
Great tool
Great tool .
This was bugging me for a long time ,found my problem in the spam-module.
check your apache errror log first
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!
+1 to checking apache error log
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.
This helped a lot!
Thank you for that hint. Found the problem. It was the pingback module in my case.
For me as well!
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
Hi, I tried your code with
Hi, Peter
I tried your code with drupal 6, and see my logs. The repetitive warnings always ends with this:
When I see the details for the first, it show:
The rests show additional messages respectively:
Message hit search cron, hit node cron, etc
So which is the guilty? Thanks
love, light n laughter
Nevermind. The guilty goes
Nevermind. The guilty goes to me:) I screwed up somehow with the input formats. In my case, Status -> Fixed. Thanks
love, light n laughter
what input forms did you screw up
What import forms did you screw up? I had the same problem as you after installing that line of code.
I gave extra allowed html
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
gausarts
love, light n laughter
fantastic solution
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.
Thanks
This was very helpful,
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.
Thanks
thanks jonwatson
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.
+1 to this. Turning off PHP
+1 to this. Turning off PHP filter, running cron and then turning it back on solved the problem.
Thank you!!!
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!!
Disabling PHP Filter worked
This also worked for me! Now if I can figure out what page or change is actually causing the problem.
...
...
Thanks to all
Disabling and re-enabling the PHP_filter worked for me. Thanks so much. Was using Drupal 6.22.
Thank you
Thank you
Brilliant
Thanks, Peter!
-------------------------------------------
Interactive Worlds and Immersive Obsessions
http://www.asifproductions.com
Any reason why this shouldn't be in core?
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.
Plus one for this debugging code
Thanks for the debugging cron code. I found this post in 2 minutes after noticing my problem. Another 2 minutes later problem solved.
Snippet's really helpful,
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?
THANKS! THIS WAS KEY TO SOLVING MY ISSUE
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.
Problem resolved - Issue with XML Site map
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
Sridhar
Acer Aspire 5745
[i5 430M, 3GB, 320GB]
Ubuntu 12.04 (Precise Pangolin)
Drupal 6.15, 7.x
DigitalOcean, Go Daddy, Rackspace,
Helped me too
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.
great little code snippet, it
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.
Every place I put this line I
Every place I put this line I get error.
Can you help with where excactly should I put it?
Managing Partner at Reasonat
OK, I have sacseed with that
OK,
I have sacseed with that but looking at my phpmyadmin I see no table named watchdog!
Managing Partner at Reasonat
Thanks a lot....
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...
Same here. The problem for me
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...
=-=
you have to increase memory on the server or most hosts: http://drupal.org/node/207036
Adding my voice to confirm
Adding my voice to confirm the usefulness of this single line of code.
Very Helpful
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.
@liquidcms: Your Debugging Method - thx!
@liquidcms:
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.
Bye
A million thanks to liquidcms
A million thanks to liquidcms for this, I found the problem with this.
You da man!
Support Nag was the culprit.
Turn off cron sitemap submit
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.
set_time_limit(0);
You can do
set_time_limit(0);
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).
facing strange cron issue
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?
>>when I run the cron from
>>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?
Another 'me too' - don't know
Another 'me too' - don't know why this is happening. :-(
__________________
Personal site: www.jeffgeerling.com
update your modules page
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.
I am running Drupal 6 and
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
PHP header: location
Hi,
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 :-)
Same problem, the code on my
Same problem, the code on my node was
Thanks a lot :)
- update -
solved with
thanks to http://drupal.org/node/102138#comment-476860
Cron run exceeded the time limit and was aborted (search_block).
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?
show each module?
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
adding file info?
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.
Disabling the PHP filter,
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.
re: Disabling the PHP filter,
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?
WOW
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
Similar Woes
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
drupal_goto
Be careful of using drupal_goto in your php_filter nodes. See #453286: drupal_goto breaks cron.php
Odd...
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
Search.module - patch to help in Drupal 6
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
How I fixed mine
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.
Garry.
What is Watchdog log?
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.
Can noone explain what Watchdog log is and how it's functioning?
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.
Watchdog is Dblog
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
http://www.tinemuller.dk/drupal/admin/reports/dblog
http://www.tinemuller.dk/drupal/admin/reports/access-denied
http://www.tinemuller.dk/drupal/admin/reports/page-not-found
http://www.tinemuller.dk/drupal/admin/reports/search
http://www.tinemuller.dk/drupal/admin/reports/updates
http://www.tinemuller.dk/drupal/admin/reports/status
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?
filter by "cron"
@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.
Peter Lindstrom
LiquidCMS - Content Solution Experts
@liquidcms - thanks for
@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?
search
cron dies during search.. go to admin/settings/search and reduce number of items to index during cron run.
Peter Lindstrom
LiquidCMS - Content Solution Experts
Thanks liquidCMS!
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 :)
In Addition
You could just go to
http://yourserverip/drupal6/cron.php
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
Outdated RSS Aggregator feed
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
This worked for me...
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.
Cheers
Robert in Oz
+1 This solves the problem in
+1 This solves the problem in my client site
--------------------------------------------------------------------------------------------------------
if you can use drupal why use others?
VicTheme.com
Thank you ... This worked for me as well
One of numerous challenges and tweaks necessary for a D5 -> D6 upgrade :-(
I like that this did not involve having to hack/customize code. :-)
Cron is really busy, even if
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
http://www.asifproductions.com
Thank you!
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.
Same here!
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.
Elysia
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
http://www.asifproductions.com
Need some help on cron.php and search module
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
Location http://59.162.218.81/drupal_dev/admin/settings/search/wipe
Referrer http://59.162.218.81/drupal_dev/admin/settings/search
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
Hostname 192.168.1.227
Operations
watchdog details after running cron.php and search enable
Type php
Date Thursday, January 14, 2010 - 18:13
User Admin
Location http://59.162.218.81/drupal_dev/admin/reports/status/tabs.css
Referrer http://59.162.218.81/drupal_dev/admin/reports/status/run-cron
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
Hostname 192.168.1.227
Operations
I want search module along with cron.php. Thanks in advanced.
I was having the same issue
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.
indexing & goto
That's this issue here
-------------------------------------------
Interactive Worlds and Immersive Obsessions
http://www.asifproductions.com
Workaround for drupal_goto
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
Had the same problem and just
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.
Subscribing
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
@rmonteroo
SuperCron
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.
http://drupal.org/project/supercron
I got this error as well. I
I got this error as well. I limited the amount of nodes in my xml sitemap and that solved the problem.
Same problem, search module stops cron from a successful run
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...
=-=
one way would be to clear the index and see if it dies at the same node.
It does appear to do that
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') {
to
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!
messaging
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.
My solution to this issue was
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.
Same problem in Open Atrium
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?
Thanks
another YES for liquid cms' logging snippet
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)
thanks!
Same for me - I migrated my
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!!
============================
Resonetrics: Better Tools for Building Brands
http://resonetrics.com
http://technologyformarketers.com
http://kittenassociates.org
http://www.linkedin.com/in/sammooreatresonetrics
it was the Search index
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.
thank you very much for this
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!
undefined function in node breaks search indexing during cron
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:
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.
Thank you
Disabling PHP Filter module solved cron problem for me. It also works as normal after re-enabling PHP Filter. Bizarre!
PHP filter here as well
Drupal 6.x, disabling and re-enabling the "php filter" module worked here as well.
Thanks!
it take me 1 week to solve this problem!!! Thanks!
Fix for me was...
Drupal 6.22
Problem was in luceneapi/lib/Zend/Search/Lucence/Index/SegmentMerger.php
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.
“Cron run exceeded the time limit and was aborted.”
@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
thomas@firstlookdesign.net
Thomas Newman
UI Developer
https://cmstom.com
Running Drupal 6.x, disabling
Running Drupal 6.x, disabling and re-enabling the "php filter" module worked for me as well.
Thank you
+1 for disabling php filter - this worked for me, but ultimately the problem was caused by an illegal mix of collations error.
Yep, same here
Yep, same here, disabled and enabling the PHP filter module allowed cron to run.
Thanks to all above
My solution - disable, uninstall, reinstall
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
Thank man, it module Backup
Thank man, it module Backup and Migrate cause
For me it was Browscap
Hello,
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");
Cheers,
Graham Leach