Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
By mike211175 on
Any help on this cron jobs problem would be greatly appreciated.
Up until about 2 days ago I had cron jobs set up (through cpanel) to run every hour. I ran cron every hour because the subscriptions module was set up to distribute new posts when cron ran, and I wanted to update the RSS feeds the site publishes (using the Aggregator summary module) frequently. This method of cron running every hour worked fine for many months.
Then I started getting errors that said:
“Cron has been running for more than an hour and is most likely stuck”
And
“Attempting to re-run cron while it is already running”.
I disabled the automatic cron running tool in cpanel, and attempted to run cron manually using the “run cron manually” link on the logs/status report page. That did not work, but gave a “Cron run failed” message at the top of the logs/status report page.
If I try to run cron manually from the logs/status page when cron is already running it just gives a “Cron run failed” message at the top of the logs/status report page and a “Attempting to re-run cron while it is already running” error on the log page. However, if I wait a long time before running cron manually, then it gives me a pop up window with over 500 pages of error messages. But there are only about 5 or 6 different error messages that keep repeating and repeating. All of the error messages refer to line 172 of the database.mysql.inc script. That script file is in the “includes” folder of the standard Drupal installation files. Lines 142 to 175 of that file are as follows
**
* Helper function for db_query().
*/
function _db_query($query, $debug = 0) {
global $active_db, $queries;
if (variable_get('dev_query', 0)) {
list($usec, $sec) = explode(' ', microtime());
$timer = (float)$usec + (float)$sec;
}
$result = mysql_query($query, $active_db);
if (variable_get('dev_query', 0)) {
$bt = debug_backtrace();
$query = $bt[2]['function'] . "\n" . $query;
list($usec, $sec) = explode(' ', microtime());
$stop = (float)$usec + (float)$sec;
$diff = $stop - $timer;
$queries[] = array($query, $diff);
}
if ($debug) {
print '<p>query: '. $query .'<br />error:'. mysql_error($active_db) .'</p>';
}
if (!mysql_errno($active_db)) {
return $result;
}
else {
trigger_error(check_plain(mysql_error($active_db) ."\nquery: ". $query), E_USER_WARNING);
return FALSE;
}
}
I have also gotten the 500 pages of error messages when running cron by going to www.mysite.com/cron.php. Like for running it manually, I either get a blank page (like it does when cron does work) if cron was already running (and there is an “already running” error on the log pages), or I get the page listing the errors if cron was not already running.
I hope that the above provides sufficient information for someone to give me some advice on how I might fix this cron problem. I would really appreciate it.
One other point is that after this problem started occurring a few days ago, I updated from Drupal 5.1 to 5.3. I hoped (but did not expect) this would solve the problem. It did not help. I upgraded by switching off the contributed modules, switching to blue marine theme, using the “push a button” upgrade method provided by my ISP in cpanel, reinstalling the contributed modules and themes, and then running update.php. That all worked fine, but cron still won’t work.
I did read the threads dealing with cron problems in the support forum and note the following:
Suggested fix #1
I gather that certain contributed modules (especially the Update_Status module) can cause problems. I disabled all the contributed modules I run (Aggregator-summary, captcha, fckeditor, legal, print, service_links, sitemenu, subscriptions, taxonomy_access) and then tried to run cron manually again, but still got the “Cron run failed” message at the top of the logs/status report page.
Suggested fix #2
Delete the search index on the page admin/settings/search. After I clicked “Re-index Site” it said that “0% of the site has been indexed. There are 493 items left to index”. This did not help the cron problem though. However, strangely, the search module still works and finds information that was indexed before I clicked the “Re-index Site: button. Nevertheless, this did not help the cron problem.
Suggested fix #3
One of the posts suggested deleting the variable 'cron_semaphore' from your variables table. I went into phpMyAdmin and found this variable, so I guess I could delete it. However, I have never deleted anything from my database (except through the administration menus), and am very nervous about tampering with the raw database. I would be extremely grateful if anyone could advise me on the risks of deleting the variable 'cron_semaphore' – what negative consequences might that have?
Questions
Is this something that I should speak to my ISP about, is it possible that they caused this problem?
Any help on this would be greatly appreciated, in particular any advice on the risks of deleting the variable 'cron_semaphore'.
Regards
Comments
my experience with the cron job already running problem
Apparently, I've had this problem for a couple days now.
After reading http://drupal.org/node/160652, I went into the MySQL 'variable' table and deleted the cron_semaphore variable and the cron_last variable. When I looked at /admin/logs/status, it said that cron had never been run and I should do something about that. So far so good.
But when I browsed /cron.php and then looked in /admin/logs/watchdog, I still got the cron running msg. So I returned to MySQL and verified that the cron_semaphore variable hadn't returned. It hadn't. That got me to thinking that the variables were cached somewhere.
About that time, I ran into an error_log file in public_html. It was filled with 'PHP Warning: MySQL server has gone away' msgs. Several attempts were made to write errors to watchdog but were unsuccessfully entered due to the MySQL problem (That's a whole different story). Among the errors encountered were "DELETE FROM variable WHERE name = 'cron_semaphore';" and "DELETE FROM cache WHERE cid = 'variables';" The first of these I'd already done manually. So I ran the second statement and then tried pulling /cron.php again. Looking at
/admin/logs/watchdog, there was the hoped for 'cron run completed entry'. Hopefully, I'm back in business for a while.
Mixed in with the other messages that didn't make it to watchdog, while the MySQL cat was away, was one stating "Cron run exceeded the time limit and was aborted." Not sure if that was the start of problems or not. But it seems there is some streamlining necessary on my end.
Good luck.
Fixed Again
I've had this problem twice now, and here's what I did this time to solve it (last time was early in the dev phase of the site; I just deleted the database and started over ;-):
http://www.midwesternmac.com/blogs/geerlingguy/cron-troubles-drupal-here...
__________________
Personal site: www.jeffgeerling.com
It is finally working again...
Thanks khyizang for your advice
After exploring many possible solutions, including increasing the allowable values for the
max_allowed_packet variable (in the my.cnf or my.ini of mysql) and the wait_timeout system variable, I finally tracked the error down to the Aggregator Summary module.
The aggregator summary module updates the RSS feeds when cron runs, and there seemed to be a single RSS feed that the aggregator summary module was getting stuck on. This resulted in cron running for hours on end.
I experimented with first disabling the module entirely, and that worked. I was then able to re-enable the module and just delete certain RSS feeds until I found the one that was the problem.
good going.
Good for finding it.
Your troubleshooting turned up that it was indeed an error (MYSQL in your case?) meaning that the cron runs could not complete successfully.
Some folk seem to have been having trouble isolating it as well as you did. What level was your php logging on? It could be that you actually SAW the triggered errors where some folk were unable to.
.dan.
How to troubleshoot Drupal | http://www.coders.co.nz/
.dan. is the New Zealand Drupal Developer working on Government Web Standards
one more comment...
I am not sure "what level php was logging on" - I did not so much inspect the error logs (other than the "recent log entries" page in drupal) as just switched things on and off until cron ran properly.
Although I do not know if it is what was causing the problem, it may have been the following:
In the past I have had trouble posting pages containing the phrases "perl", "test
method" and "bcc". In those cases I got a "page not found" error when posting new content containing those phrases. The problem was caused by modsecurity settings catching those phrases because it thought that they were unix commands or SQL strings or something. That problem was fixed by adjusting the modsecurity settings to let those phrases through.
While I was turning feeds in aggregator summary on and off, and deleting and re-adding them, when troubleshooting for cron, I noticed that there was one feed that contained "bcc" and I could not re-enter it into aggregator summary, but I was getting the "page not found" error like sometimes got when trying to post new content pages containing "bcc". In other words, it seems that the modsecurity settings were blocking "bcc" for adding feeds to the aggregator summary module.
I got my host to change the mod security rules to allow me to add "the bcc feed" to aggregator summary, and afterwards cron was running fine. I am still not sure that that was the one feed that was causing the cron problems, but if modsecurity is active during cron - I do not really know what it is or how it works - then it could well have been stalling cron by stopping the process when the bcc feed tried to update during cron???
same problem with drupal 6
Hi all
I'm experiencing the same problem with drupal 6 (using mysqli).
cron.php is called every hour by crond. sometimes it ends up with lots of "MySQL server has gone away" errors in my server's logfiles. (PHP error_reporting = E_ALL & ~E_NOTICE).
The following two (1h und 2h later) cron jobs then report these errors to the watchdog: 1st, 1h after mysql gone away errors: “Attempting to re-run cron while it is already running”, 2nd, after 2h: “Cron has been running for more than an hour and is most likely stuck”.
As mike I was able to trace it down to the feed aggregator module. I found one feed that sometimes has more than about 30-60s to load. So it seems that when one feed has too long to be loaded by cron, the mysql connection gets closed by the mysql server in the meantime because of a mysql timeout (on my server about 20s, not the same as the php execution timeout).
Because this feed (and so does the cron) most of the time works just fine I wrote my own "feed" to trace the problem. my "feed" has always a long loadtime of 30s:
So i added a new feed in Feed Aggregator, linked to my own new "feed".
Always when I call (manually or by crond) cron.php (which then tries to load my "feed"), I get these MySQL gone away errors.
Adding "mysqli.reconnect = On" to php.ini solved the problem resp. can be used as workaround, but I don't want this option to be On all the time.
So, I think the feed aggregator or even the drupal db functions should reconnect atomatically once or twice when the db connection get's lost.
Could someone else try to reproduce these errors? Thanks
same problem, same time - I FIXED it for my site!!!
Hi plexato,
I am also using Drupal 6.0:
MySQL 4.1.22
PHP 5.1.4
Hosted by GoDaddy.
This morning (about an hour after you posted your message), I noticed that my search bar wasn't finding my most recent posts. I figured that my site just wasn't fully indexed. Sure enough, my status report said that only about 80% of my site had been indexed. I then saw that the last time cron ran was over 18 hours ago. I clicked on the link to "run cron manually"... a red message bar came up saying that " cron run failed " . I tried running cron.php from my site and got lists and lists of MySQL gone away errors.
I simply refreshed the cron.php page again and the MySQL gone away errors went away, but cron still failed to run.
I tried adding "mysqli.reconnect = On" to php.ini - - still nothing.
My Recent Log Entries showed up with "Attempting to re-run cron while it is already running" and "Cron has been running for more than an hour and is most likely stuck"
I fixed the problem though: a new user created an account late last night a few hours after my most recent successful cron job. The new user was obviously some kind of a spam bot (login attempt failed for penis@penisgrowth.com and new user - bigteoq93w with an email address of penis@penisgrowth.com).
I simply deleted this user and my cron jobs now run successfully. I'm gonna try to find a way to block spam bots like this because I'd like my site to allow anybody anywhere to create a user account without necessarily waiting for admin approval. But I really can't afford to have another spam bot screw up my cron jobs again. I hope that the spam bot just screwed up my cron jobs and didn't get access to any files it shouldn't have. That is the first time I have had a spam bot create an account on my site. Of course, I've only had my site up and available for about a week at this point. Gonna look into having the most secure site possible now!
In summary: Check out any of your new users in your Recent Log Entries. If they look suspicious, investigate them and get rid of them. Hope that helps. I'll be checking this thread again to see any updates on this. Good luck!
Sincerely,
Andrew G
Feed Aggregator: Error: MySQL has gone away (Drupal 6.0)
Hi Andrew
First, to complete my problem description. I'm using Drupal 6.0 with MySQL 5.0.45 (using mysqli connector) and PHP 5.2.3 (CGI) on Apache 1.3.
Thanks, Andrew, for your response and the hint to check for suspicious user accounts. But in my case it can't be a malicious user account. In my installation user registration is turned off and there are just two users, which I created myself.
As much as I found out, this "MySQL has gone away" error occurs, when there's no interaction with the database for more than about 20s (depends on MySQL connection timeout settings). This can be the case when some function runs too long. So there might be different problems generating the same MySQL error.
In my case it's definitely the feed aggregator module, which runs too long because of a feed that has very long to load. I can reproduce the error by adding my "feed" which has at least 30s to load and removing mysqli.reconnect = On from php.ini (see previous comment)
The first two MySQL errors are these:
They are generated after my own "feed" wait.php has been loaded by feed aggregator and the MySQL connection has timed out. The Feed aggregator tries to write the new feed items to the database, but gets a MySQL error, watchdog then tries to write this MySQL error to the database. This is the point at which Drupal is no more capable to catch the errors itself and the errors are sent to the servers error log (and the browser of the user, calling cron.php).
I'm not sure what cron does with user accounts, so it's hardly to say where your problem occurred.
Unless you mixed up the sequence of the incidents and errors in your case, it could be that the problem has nothing to do with this spam user account. When I call cron.php manually, I get these MySQL errors. After that I can't call cron.php for at least one hour and watchdog reports "Attempting to re-run cron while it is already running". After one hour it reports "Cron has been running for more than an hour and is most likely stuck". After this last error message I can call cron.php again, resulting in the same MySQL errors. I think this is because ther's a semaphore used to prevent drupal from running two or more crons at the same time. It seems that this semaphore is removed after the moment when watchdog reports "cron... is most likely stuck". (This semaphore can be removed manually from the database, see system table and emty cache.)
Following your problem description, I guess, at the moment you set mysqli.reconnect = On this semaphore still existed and cron failed because of that. After one hour the semaphore was removed and without calling cron.php again, you deleted this user. Running cron.php after these steps it's not clear whether deleting the user or setting mysqli.reconnect = On solved the problem.
That's just speculation, but maybe you can try to remove mysqli.reconnect = On from php.ini and see what happens. Good luck!
Sincerely
plexato
"MySQL server has gone away" error in admin interface and cron
Please excuse my double-post. Because it's an additional information and not just a small correction I've chosen to write a new comment.
Until now I reported the "MySQL has gone away" from the feed aggregator module just in connection with cron, but i forgot to mention that I can produce the same error using the feed aggregator's admin interface (http://www.X_DOMAIN_X/admin/content/aggregator/update/5) when updating a feed, that has a long loading time. (to get reproducible results I'm just using my "feed" that has at least 30s to load, see previous comments.)
In case of updating the feed manually using the admin interface the MySQL errors look this way (just the first two of a whole bunch of similar errors):
Feed Aggregator or MySQL itself
Sorry the malicious user solution wouldn't work.
I took
mysqli.reconnect = Onout of my php.ini and haven't seen any changes as of yet. I also disabled my feed aggregator yesterday after reading your message because I hadn't been using it (though I definitely plan to enable feeds again on my site in the future). That could have been the reason my cron is running successfully again - although I totally realize that disabling your feed aggregator is not a viable solution at all by any means.I see you've also posted on http://drupal.org/node/227445. Have you tried any of the bug fixes on http://dev.mysql.com/doc/refman/5.0/en/gone-away.html? I wouldn't know where to start in the suggestions they have on that page, but a lot of the message posts I've read in the Drupal forums say that it's an issue with MySQL and not with Drupal.
Since I do plan to re-enable my feed aggregator in the future (and I'd like it to work with cron updating for me), I'll try re-enabling my feed aggregator and setting up some RSS feeds this week. I'll let you know if I come across the MySQL gone away errors again or any cron job problems related to the feed aggregator.
Sincerely,
Andrew G
had to update to 6.1
Hello again,
plexato - have you had any success with cron on your feed aggregator? I was going to try some RSS feeds, but ended up working with updating Drupal 6.1 for most of the time.
After updating to Drupal 6.1 this week, I've had some more problems with re-running cron and "MySQL server has gone away." At about 10:30am, I tried to run cron to search for available updates and make sure my site was indexed for my search bar to work - cron run failed. I figured out that all my php files had extra spaces at the end of them (see the FAQ about "headers already sent" at: http://drupal.org/node/1424) and that some of my image files that were referenced perfectly fine in 6.0 hadn't been updated in their locations in 6.1. I probably did solve the problem by fixing those issues, but I caught the problem and fixed the problem within fifteen minutes. My cron suddenly (mysteriously) started working again exactly one hour later at 11:30am. (right at the same moment that I received the error in my log "cron has been running for more than an hour and is most likely stuck") So, maybe you end up being stuck for an hour troubleshooting any cron-run problems because of the "cron has been running for more than an hour" message? My site is now running perfectly fine, but I was not running any feed aggregator at all and still ended up with MySQL server gone away messages at the available updates page:
Warning: MySQL server has gone away query: INSERT INTO watchdog (uid, type, message, variables, severity, link, location, referer, hostname, timestamp) VALUES (1, 'php', '%message in %file on line %line.', 'a:4:{s:6:\"%error\";s:12:\"user warning\";s:8:\"%message\";s:183:\"MySQL server has gone away\nquery: SELECT p1, p2, p3, p4, p5, p6, p7, p8 FROM menu_links WHERE menu_name = 'secondary-links' AND link_path = 'admin/reports/updates'\";s:5:\"%file\";s:52:\"/home/X_DOMAIN_X/html/includes/menu.inc\";s:5:\"%line\";i:871;}', 3, '', 'http://www.X_DOMAIN_X.com/admin/reports/updates', 'http://www.X_DOMAIN_X.com/admin/reports/status', 'X_IP_X', 1204560508) in /home/X_DOMAIN_X/html/includes/database.mysqli.inc on line 128
Warning: MySQL server has gone away query: INSERT INTO watchdog (uid, type, message, variables, severity, link, location, referer, hostname, timestamp) VALUES (1, 'php', '%message in %file on line %line.', 'a:4:{s:6:\"%error\";s:12:\"user warning\";s:8:\"%message\";s:485:\"MySQL server has gone away\nquery: \n SELECT m.load_functions, m.to_arg_functions, m.access_callback, m.access_arguments, m.page_callback, m.page_arguments, m.title, m.title_callback, m.title_arguments, m.type, m.description, ml.*\n FROM menu_links ml LEFT JOIN menu_router m ON m.path = ml.router_path\n WHERE ml.menu_name = 'secondary-links' AND ml.plid IN (0)\n ORDER BY p1 ASC, p2 ASC, p3 ASC, p4 ASC, p5 ASC, p6 ASC, p7 ASC, p8 ASC, p9 ASC\";s:5:\"%file\";s:52:\"/home/X_DOMAIN_X/html/includes/menu.inc\";s:5:\"%line\";i:909;}', 3, '', 'http://www.X_DOMAIN_X in /home/X_DOMAIN_X/html/includes/database.mysqli.inc on line 128
Warning: MySQL server has gone away query: INSERT INTO watchdog (uid, type, message, variables, severity, link, location, referer, hostname, timestamp) VALUES (1, 'php', '%message in %file on line %line.', 'a:4:{s:6:\"%error\";s:12:\"user warning\";s:8:\"%message\";s:295:\"MySQL server has gone away\nquery: UPDATE cache_menu SET data = 'a:2:{s:4:\\"tree\\";a:0:{}s:10:\\"node_links\\";a:0:{}}', created = 1204560508, expire = 0, headers = '', serialized = 1 WHERE cid = 'links:secondary-links:page:admin/reports/updates:1'\";s:5:\"%file\";s:53:\"/home/X_DOMAIN_X/html/includes/cache.inc\";s:5:\"%line\";i:109;}', 3, '', 'http://www.X_DOMAIN_X.com/admin/reports/updates', 'http://www.X_DOMAIN_X.com/admin/reports/status', 'X_IP_X', 1204560508) in /home/X_DOMAIN_X/html/includes/database.mysqli.inc on line 128
It might not only be the feed aggregator, although the long loading time in your aggregator could be a problem.
Other than that, having fun with 6.1!
Sincerely,
Andrew G
#327066: Warning: MySQL
#327066: Warning: MySQL server has gone away: recursive error reporting
I too came across the cron problem
I too came across the cron problem, but only today.
Thankfully I read all the information that I could find, followed the given links and tips, and finally arrived here.
I also had a ghost as a registered user, and after deleting the ghost, cron was run successfully in no time!
Regards,
Merja S
Thanks Problem Solved
I know this is against an old post, but this simple solution worked for me, I had a couple of new "users", and even though the accounts were in status blocked.
I had been searching for a solution to this same problem when I saw your post and gave it a shot. Problem Solved in Record time!
I had been mulling over this for an hour or so, disabling modules, testing etc. So you probably saved me another few hours.
Thanks!
Image import was hanging . . .
For me, I had to disable Aggregator and then cron ran successfully. After that I got an error message that image import was hanging on an 'invalid jpg' so I deleted the offending jpg. All is well now.
Curiously, I am also on GoDaddy. Hope this helps someone.
lunk_rat is Acquia Certified Grand Master
Aggregator is still causing
Aggregator is still causing headaches to the Cron process even on Drupal 6.10
cron_semaphore yes but...
In my case simply deleting the cron_semaphore didn't work because cron would fail again. Nothing was logged un the Drupal log, but I did finally see a page of "MySQL server has gone away messages" and realized that among them was a failed attempt to delete from the cache of the Administration Menu. Turns out after wipe and rebuild of Administration Menu and flush of the caches it was able to finally complete a cron run. BTW this was in Drupal 6.14
Exact same issue here =/
Exact same issue here =/
Found an old tip
I had similar problems, once again, Cron was totally stuck.
Looked for help, and found this
http://www.digitaledgesw.com/node/21 
I don't know if that is an optional solution, or even if it is "suitable", but following the instructions got me out of trouble, and everything seems to be working ok now.
This worked for me.
This worked for me. http://drupal.org/node/382682
1. Track down which module is causing the issue with the code posted at the link, there is code for D5 and 6.
2. Disable module causing issue
3. Run this in database
4. Run cron manualy a couple of times.
Drupal 7
I've been going crazy for the last day trying to solve this problem in Drupal 7. Finally figured out that the cron_semaphore row moved from the Variable table to a new Semaphore table (where I think it's called, simply, cron). So the rows that need deleting are different in D7.
Finding which module is tripping your cron
A quick way of finding which module is the cause of your problems is:
Go to includes/common.inc
Go to function drupal_cron_run() on line 5083 (Drupal 7)
find the line
foreach (module_implements('cron') as $module) {and insert on the next line
echo $module."<BR>";after the end of the foreach statement insert
die();The last module echoed will be the cuplrit!
Remember to undo these changes
THANK YOU
Even though this post is 5 years old, this is a life saver. Had a site that's cron job wasn't running for 8 months! Constant attempts to get it restarted, increasing resource limits, installing different cron managers, etc. failed. By simply doing what is listed above showed me that the problem was with the Link Checker module. Disabling that solved the problem immediately.
Thank you kindly,
Travis Johnston
Creo Coding - Let's Start Our Journey!
Owner and Web Developer
http://www.creocoding.com
Facebook - Facebook.com/CreoCoding
LinkedIn - http://lnkd.in/rQrdS7