hi!

I am looking on my watchdog entries, and I found this two entries together

warning 19/07/2007 - 21:30 Attempting to re-run cron while it is already running. Anonymous
warning cron 19/07/2007 - 21:30 Attempting to re-run cron while it is already running. Anonymous

But I understand why the cron want to run 3 times (I have set cron run 1 times for a hour on server)

What can be problem/reason of it?
Thanks

Igor
somvprahe.sk

Comments

igorik’s picture

I want to write "I don't understand" of it...

Igor Krutak
www.somvprahe.sk

cyberswat’s picture

Install the devel module and use it's variable editor located at devel/variable to delete the variable cron_semaphore ... this will allow your crons to run again.

BradM’s picture

I get this same error. Installed the devel module and followed the suggestion, but cron still fails. Any other suggestions?

BradM’s picture

I don't mean to vent spleen but after working on this problem for over a month, and reading through every related post, a solution can't be found... and I'm not the only person dealing with this.

Problem: cron doesn't work with Drupal 5.3
Error: logs state "Attempting to re-run cron while it is already running." But it is *not* running.
"Solution": told to delete cron_semaphore (and any other cron* listings) in the variables table, and try again.

I've tried everything else from modifying common.inc, to completely uninstalling modules, to indexing only 10 nodes per run, to removing Update_status module, etc, etc. Yet cron continues to fail. And even when cron_semaphore has a value, the status report still tells me that cron has never been run.

The main problem lies with the fact that I, and many others, are new to drupal and can only take things so far. All I've seen are repeated answers stating to delete cron_semaphore but that is obviously not working for many of us... and many messages for further help go unanswered.

Can anyone who knows this software inside out offer any more insight? It's becoming a real struggle as I see over 2000 nodes (and counting) in the queue waiting to be indexed. No notifications are being sent out, and members are becoming less interested in a portal that isn't working correctly. Surely someone somewhere has found this same error and come up with a solution that has not yet been posted to the forums. Is it a particular module? Does it have to do with mysql itself? Is there some other code to add that might help figure out what is going on?

Any insight is very much appreciated...again sorry to be a little rough around the edges but the aggravation level is quite high right now.

Thanks.

dman’s picture

Without being able to replicate it, I dunno what your highly-paid personal support team can do for you.

cron begins, and makes a 'semaphore' note that it's begun.
It runs its queued jobs
then removes the semaphore.

If it tries to begin when the semaphore is active, it drops out with that error.

THEREFORE
for some reason the last step of the previous run isn't hit.
First guess would be a timeout.
Second guess is a fatal error during the run.

SO
- delete the semaphore
- invoke the cron.php directly from the browser - do you see any errors?
- inspect the semaphore - is it still there? It shouldn't be if things happened

- inspect your cron logs on the server. errors triggered by the cron demon go somewhere usually.

.dan.
How to troubleshoot Drupal | http://www.coders.co.nz/

BradM’s picture

I dunno what your highly-paid personal support team can do for you.

Well I expected as much. Therein lies the problem with this and other open-source portals (and I've been part of many, coded some, and gave assistance to others.) Whenever something like this is brought forth, people take it as a personal attack and respond just like you did, which never helps the matter and is just a waste of everyone's time.

- delete the semaphore
That's the standard reply. Done and done, multiple times. Search the forum, you'll see *many* replies that this doesn't work.
- invoke the cron.php directly from the browser - do you see any errors?
It doesn't output any html.
- inspect the semaphore - is it still there? It shouldn't be if things happened
It's always there, just with a different timestamp.

Believe me I do see that you are trying to help, but seriously, when you lead off with sarcasm and a personal attack directed at the poster, it doesn't benefit anyone.

dman’s picture

And the two suggestions you ignored were:
- How can anyone who's not seeing this problem replicate it?
- What did your cron logs say?

Don't you see that there's not a lot more suggestions to offer if you cannot describe what makes your personal setup different from the huge majority of successful users?
How can anyone remotely debug a problem that just doesn't happen?

I briefly stepped through the expected behaviour in the hope that it would help you trace what's going wrong on your specific system. Sometimes that leads to an "ah-hah" moment. Obviosly that didn't work this time.
You asked for insight - an explanation of the expected process is all I can offer. Where do YOU think the process broke down?

Are you confident that the cron run completed successfully?
Did ANY of the expected actions actually happen?
Have you looked at the watchdog logs?
Is it just that the flag is not being removed?
Is there some permission on the database that would stop the semaphore being removed?
Have you looked at the cron logs?
Can you log the database queries? Use devel.module if needed.
I don't even know what sort of host (windows, linux, mysql, pgsql, php version, drupal release version, extra modules) you've got.

What response do you really expect?

If this is a real bug, its status is "Cannot replicate, need more info".

BradM’s picture

Whoa, man, take a deep breath. I'll use your lengthy, angry, list of things to check and go from there. Honestly, for the sake of your actual clients, I hope you have more patience with them. Otherwise, you're in the wrong business.

Feel free to use this thread to further berate me, but the whole thing has become a little childish for my tastes. I'll just go about my business and hope I can get this thing fixed.

NickWebman’s picture

lol

DanilaD’s picture

Had the same problem.

Deleting cron_semaphore and clearing cache helped. Thanks a lot!

I suspect initially cron dropped because of some problems with Messaging - Notifications...

ashhishhh’s picture

thank you so much
Regards,
Ashish

vishalkhialani’s picture

thanks cyberswat your post helped me out. I was able to get my cron to start working again.

redcrackle.com

nhod’s picture

Flamewars aside, this is still a bug. This problem shouldn't happen. It has happened to me before in several different Drupal installations. I am fairly experienced in how to fix it, but the fact remains that I should not have to. This is a critical Drupal function. If cron is not actually running Drupal should not erroneously report that cron is running. The problem is compounded on load-balanced clusters because you don't always know which server is getting hit, so checking the logs is easier said than done.

The semaphore is intended to solve this problem, but it does not. It remains set when cron is not running if cron crashes. There are a host of reasons this may occur, but the fact that it does occur is a bug.

I think that's what BradM is trying to say.

erlendstromsvik’s picture

Remember to clear the cache for your Drupal installation.
If not, and this is a bit inane, Drupal will continue to keep the cron_semaphore value in the cached configuration and continue to happily report that cron is still running.

Erlend Strømsvik
erlend@nymedia.no
Ny Media AS - www.nymedia.no

ceejayoz’s picture

Thank you very much for the cache note - helped me a lot.

pjthompso’s picture

Restarting is made worse as I am also running memcached daemons for the cache.

Instead of deleting the entries from "cache" database table and, deleting the cron_semaphore, does anyone have a good way of deleting the cron details from (memcached) cache?

I resorted to "killall memcached", restarting memcached, deleting the semaphore row from variables, and running cron again (painful).

Is there a better way (I know there is memcacheapi admin tool "on the way")??

Paul

boclodoa’s picture

I had the same problem

I don't know if understood right what you say, but (after I deleted the 'cron_semaphore' row in the 'variable' table) I cleared all the content in the 'cache' table (via phpmyadmin)... then I ran the cron successfully

Rob T’s picture

THanks for the post here. I ran into this problem, and after clearing my "variables" row from the cache table in phpmyadmin and deleting the cron semaphore row, I was able to run cron again.

Stephen Winters’s picture

subscribe

dman’s picture

FYI, a cross-reference
Here's a success story of someone successfully following the troubleshooting steps and finding the answer.

Your exact answer may be different but the process should help.

.dan.
How to troubleshoot Drupal | http://www.coders.co.nz/

lightweight’s picture

If you can't get to the bottom of it via the advise given above... have you perhaps got any custom or alpha level modules installed? It's possible that the cron.php run is silently failing with a php error in one of the module cron hooks and is therefore not unsetting the cron_semaphore...

cmsproducer’s picture

I am troubleshooting the same problem, or a problem that has similar manifestations and I find that the modules "update status" is causing the Drupal 5.1x to give a constant 404 error because it is causing a 500 error (timeout/exhausting resources) all the time and even crippling cronTab.
I find that generally disabling s number of modules makes it easier for Cron to run without sticking

-----
iDonny Productions: Drupal CMS Implementation, Theme UI/UX Design & Development, and Web Standards

awesomeg’s picture

I had the same problems, and executed the following steps:
1) connect to your database
2) execute: delete from variable where name='cron_semaphore' or name='cron_last';
3) execute: delete from cache;

Would appreciate some feedback if this was helpfull for you.

everydayjones’s picture

I deleted both cron_semaphore and cron_last and deleted from cache, but now when i try to run the cron manually, cron_last doesn't show up in the variable list (in Devel Module) and it says that my cron has never run (from the admin/logs/status page).

Please advise how I can fix this.

ljangler’s picture

Thank you. This worked for me.

mdowsett’s picture

I ran the commands in phpmyadmin successfully....but then tried to rerun cron manually and I get the error that running it failed.

In the Status Report, it reset things to say that Cron has never been run but running the cron job manually continues to bring the same result - failure.

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

Upgrade Status is disabled.

I'm running Drupal 6.9

HELP! :)

kiborg’s picture

Do you get internal server error page?

tran_tien’s picture

Worked for me. Thank you.

mareks’s picture

it did the trick for me. thanks

ami7878’s picture

Worked for me as well

edvanleeuwen’s picture

I had the same problem. After adding a watchdog statement, I noticed that cron was in a loop. I disabled modules until I found out that update status was the culprit.

Best regards,

Ed

mdowsett’s picture

I can't believe that this issue is reported MANY times (I've found a couple dozen different threads with very frustrated people) over the past two+ years and there is no fix for it.

I guess I'm just lucky that it's taken me so long to be affected by it.

Frustrating.

leobaby’s picture

I'm reporting this error as well.

Every time I upgrade my site it takes me an entire day to get it back up and running again. So here I am 9:30 on a Saturday night fighting with "Attempting to re-run cron while it is already running". Hopefully it's the last problem. Hopefully I can get to the bottom of it.

aaronbauman’s picture

the cron_semaphore is the only reason that you would get this message.
Check common.inc - it's the only variable that's checked to trigger this message. period.

you may be running into a caching issue at various layers of your webserver stack.
try dumping your drupal cache.
then try restarting apache.
then try restarting mysql.
if none of these work, hack common.inc temporarily and insert variable_del('cron_semaphore') right above variable_get('cron_semaphore', FALSE)

any luck?

jwarner’s picture

I run MySQL on a Siteground Shared hosting site and don't have the option of restarting MySQL or even FLUSHing tables, yet even after deleting the cron_semaphore variable Drupal said cron was still running.

I found that inserting a value for cron_semaphore in the variable table with an old timestamp value did the trick, since Drupal releases long-running crons:

INSERT INTO variable VALUES ('cron_semaphore', 'i:0;')
sean_e_dietrich’s picture

This worked for me. Thanks!

Antinoo’s picture

I remember I solved this by deleting the cron_semaphore variable and clearing the cache.

HTH.

mike15’s picture

I might have seen a single instance where someone indicated that cron might be failing due to a search module being enabled. In my case, in order to fix the issue discussed here, I had to run "delete from variable where name='cron_semaphore' or name='cron_last'" as well as clear the cache. That didn't help until I disabled the actual search Drupal core module.

Since search is a main dependency of the content indexing, how would you go about enabling it? If I enable it again, the cron breaks again...

Sometimes enforcing a manual cron run, results in a blank screen at this URL: http://www.domain.com/admin/reports/status/run-cron

Reloading the page after enabling Search module and you get "Cron run failed". The watchdog is showing "Attempting to re-run cron while it is already running."

Does anyone experienced similar behavior?
Running 6.10 release at the moment.

Thanks,
Mike

nathanZ’s picture

Quote:
"I might have seen a single instance where someone indicated that cron might be failing due to a search module being enabled. In my case, in order to fix the issue discussed here, I had to run "delete from variable where name='cron_semaphore' or name='cron_last'" as well as clear the cache. That didn't help until I disabled the actual search Drupal core module."

Yes, this procedure DOES work.

Delete "cron_semaphore" and "cron_last" from variable and clean cache without stopping search module DOES NOT work.

Thanks.

NZ

KoCo’s picture

I confirm the previous two posts.
Turning off 'search module', clearing cache and cron_ variables made cron working again.

Is there an update coming for this?

Anonymous’s picture

I have struggled with this for ages! I can confirm that turning the search module off made my cron run fine from the status report page such that the accounts reminder module is finally sending out reminders.

thinkpadius’s picture

Here's what I've done so far:

delete cron semaphore + run cron = fail
delete cron semaphore + flush all caches + run cron = fail
flush all caches + delete cron semaphore + run cron = fail
run cron manually = fail
run /cron.php = fail
empty cache using phpmyadmin + delete cron semaphore + run cron = fail
turn off Search 404 Module + turn of search module + delete cron semaphore + flush all caches + run cron = fail
I've also turned off a host of other modules too, and run cron.

I had this problem after a bout of new module installations yesterday and the problem was fixed by the good ol "delete cron semaphore + flush cache" game, but this time I've added the SEO friend and SEO Reports module. Its possible that they conflict; but a) why would they? and b) its a real pain that this is happening.

I'm using siteground + cpanel hosting. So have limited database access + control options (any idea how to contact them for better controls?)
I'm using php 5.2.9, drupal 6.16

Your thoughts would make life better! thanks for the support.

amandasteele16’s picture

struggling for days, finally a solution! Thanks so much.

Amanda

vkr11’s picture

Subscribing.

-Victor
Better way to search drupal.org - http://drupalsearch.org

NorthPort’s picture

I'm having the same issue as well.

Although the issue is not resolved. I have followed the steps others have suggested.

1. Delete cron_semaphore in the variables table
2. Disable and uninstall update_status module
3. Clear cache
4. Manually run cron.php (refreshing it).

The site now loads correctly, but of course is not alerting me to module updates. This seemed to be triggered approximately the same time as I enabled the aggregator module.

cheers,
David

menteb’s picture

I just truncated the watchdog table and it works.

lewisholden’s picture

Hi guys,

I'm running Drupal 6.14 on MySQL database, v5.0.45, PHP 5.2.10, on a shared Apache/2.0.61 (FreeBSD) mod_python/3.3.1 Python/2.5.1 mod_ssl/2.0.61 server.

Running the following modules:
ACL 6.x-1.0
Forum Access 6.x-1.0
Path Access 6.x-1.x-dev
Actions permissions 6.x-1.8
Role Weights 6.x-1.5
Content 6.x-2.6
Content Copy 6.x-2.6
Content Permissions 6.x-2.6
Embedded Audio Field 6.x-1.15
Embedded Image Field 6.x-1.15
Embedded Media Field 6.x-1.15
Embedded Media Thumbnail 6.x-1.15
Embedded Video Field 6.x-1.15
Embedded Wave Field 6.x-1.15
Fieldgroup 6.x-2.6
Location CCK
Node Reference 6.x-2.6
Number 6.x-2.6
Option Widgets 6.x-2.6
Text 6.x-2.6
User Reference 6.x-2.6
Bulk Export 6.x-1.0
Chaos tools 6.x-1.0
Chaos Tools (CTools) Plugin Example 6.x-1.0
Page manager 6.x-1.0
Views content panes 6.x-1.0
Archive 6.x-1.3
Aggregator 6.14
Blog 6.14
Blog API
Book 6.14
Color 6.14
Comment 6.14
Contact 6.14
Content translation 6.14
Database logging 6.14
Forum 6.14
Help 6.14
Locale 6.14
Menu 6.14
OpenID 6.14
Path 6.14
PHP filter 6.14
Ping 6.14
Poll 6.14
Profile 6.14
Search 6.14
Statistics 6.14
Syslog 6.14
Taxonomy 6.14
Throttle 6.14
Tracker 6.14
Trigger 6.14
Update status 6.14
Upload 6.14
Block 6.14
Filter 6.14
Node 6.14
System 6.14
User 6.14
GMap Debugging
Location Generate 6.x-3.1-rc1
Messaging debug 6.x-2.2
Calendar Signup 6.x-2.x-dev
Date Picker 6.x-2.x-dev
Event 6.x-2.x-dev
Fbconnect 6.x-1.0-beta8
Image 6.x-1.0-beta3
Image Attach 6.x-1.0-beta3
Image Gallery 6.x-1.0-beta3
Image Import 6.x-1.0-beta3
ImageMagick Advanced Options 6.x-1.0-beta3
LM PayPal 6.x-1.0
LM PayPal Donations 6.x-1.0
LM Paypal Paid Adverts 6.x-1.0
LM PayPal Subscriptions 6.x-1.0
GMap 6.x-1.1-rc1
GMap CCK Field 6.x-1.x-dev
GMap Extra Baselayers 6.x-1.x-dev
GMap Location 6.x-1.1-rc1
GMap Macro Builder 6.x-1.1-rc1
GMap Marker List (ALPHA) 6.x-1.x-dev
GMap Overlays 6.x-1.x-dev
GMap Taxonomy Markers 6.x-1.1-rc1
GMap Tracks 6.x-1.x-dev
GMap Views Integration 5.x-1.1-rc1
Location 6.x-3.1-rc1
Location Add Another 6.x-3.1-rc1
Location Fax 6.x-3.1-rc1
Location Phone 6.x-3.1-rc1
Location QuickGeocode 6.x-1.x-dev
Location Search 6.x-3.1-rc1
Node Locations 6.x-3.1-rc1
User Locations 6.x-3.1-rc1
Mime Mail 6.x-1.0-alpha1
Mime Mail CSS Compressor 6.x-1.0-alpha1
Simplenews 6.x-1.0-rc6
Simplenews action 6.x-1.0-rc6
Simplenews on register 6.x-1.0
Simplenews Statistics 6.x-2.1
Simplenews Template 6.x-1.0-beta3
Messaging 6.x-2.2
Messaging Mime Mail 6.x-2.2
Messaging PHPMailer 6.x-2.2
Messaging Privatemsg 6.x-2.2
Messaging XMPP 6.x-2.2
Simple Mail 6.x-2.2
Simple messaging 6.x-2.2
SMS Messaging 6.x-2.2
Twitter Messaging 6.x-2.2
Basic meta tags 6.x-1.2
Extra meta tags 6.x-1.2
Nodewords 6.x-1.2
Site verification 6.x-1.2
Content Notifications 6.x-2.2
Notifications 6.x-2.2
Notifications Autosubscribe 6.x-2.2
Notifications Lite 6.x-2.2
Notifications UI 6.x-2.2
Notifications Views 6.x-2.2
Taxonomy Notifications 6.x-2.2
Group Admin 6.x-1.2
OG Hide Membership 6.x-1.0-alpha1
Organic groups 6.x-2.0
Organic groups access control 6.x-2.0
Organic groups actions 6.x-2.0
Organic Groups Notifications 6.x-2.0
Organic groups Views integration 6.x-2.0
Account Reminder 6.x-1.2
Autoload 6.x-1.3
Checkbox Validate 6.x-1.1
Comment RSS 6.x-2.2
Contact link 6.x-1.0
Embedded Inline Media 6.x-1.15
Iconizer 6.x-1.1
Legal 6.x-2.2-beta4
Login destination 6.x-2.5
LoginToboggan 6.x-1.5
Menu Trails 6.x-1.0
Node breadcrumb 6.x-1.0-beta6
Poormanscron 6.x-1.1
Remember me 6.x-2.1
Scheduler 6.x-1.6
Service links 6.x-1.0
Similar entries 6.x-1.1
Taxonomy Access Control 6.x-1.0
Taxonomy Browser 6.x-1.4
Token 6.x-1.12
Token actions 6.x-1.12
TokenSTARTER 6.x-1.12
Troll 6.x-1.x-dev
User Import 6.x-2.3
User Import OG 6.x-1.1
Userplus 6.x-2.3
Userplus actions 6.x-2.3
PDF version 6.x-1.10
Printer-friendly pages 6.x-1.10
Send by e-mail 6.x-1.10
Rules 6.x-1.1
Rules Administration UI 6.x-1.1
Rules Forms support 6.x-1.1
Rules Scheduler 6.x-1.1
Rules Simpletest 6.x-1.1
Bayesian filter 6.x-1.0
Custom filter 6.x-1.0
Duplicate filter 6.x-1.0
Spam API 6.x-1.0
Spam node age filter 6.x-1.0
Spam Surbl filter 6.x-1.0
Spam URL filter 6.x-1.0
CAPTCHA 6.x-2.0
Image CAPTCHA 6.x-2.0
Taxonomy context 6.x-2.0-alpha3
Cart 6.x-2.0-rc7
Conditional Actions 6.x-2.0-rc7
Order 6.x-2.0-rc7
Product 6.x-2.0-rc7
Store 6.x-2.0-rc7
Attribute 6.x-2.0-rc7
Catalog 6.x-2.0-rc7
File Downloads 6.x-2.0-rc7
Payment 6.x-2.0-rc7
Reports 6.x-2.0-rc7
Roles 6.x-2.0-rc7
Shipping 6.x-2.0-rc7
Shipping Quotes 6.x-2.0-rc7
Tax Report 6.x-2.0-rc7
Taxes 6.x-2.0-rc7
Cart Links 6.x-2.0-rc7
Google Analytics for Ubercart 6.x-2.0-rc7
Product Kit 6.x-2.0-rc7
Stock 6.x-2.0-rc7
Flatrate 6.x-2.0-rc7
U.S. Postal Service 6.x-2.0-rc7
UPS 6.x-2.0-rc7
Weight quote 6.x-2.0-rc7
2Checkout 6.x-2.0-rc7
Authorize.net 6.x-2.0-rc7
Credit Card 6.x-2.0-rc7
CyberSource 6.x-2.0-rc7
Google Checkout 6.x-2.0-rc7
Payment Method Pack 6.x-2.0-rc7
PayPal 6.x-2.0-rc7
Test Gateway 6.x-2.0-rc7
jQuery Update 6.x-1.1
External Links 6.x-1.7
Wysiwyg 6.x-2.0
Insert view 6.x-1.0
Views 6.x-2.7
Views Bulk Operations 6.x-1.8
Views exporter 6.x-2.7
Views UI 6.x-2.7
Advanced Poll 6.x-1.x-dev
Advanced Poll Converter
Voting API 6.x-2.3

I've tried:

1. Deleting the "cron_last" and "cron_semaphore" rows, clearing the cache.
2. Disabling Update, Search, LM Paypal, Poormanscron
3. Clearing the Watchdog tables

And I still can't get the Cron to run / finish its run. Thoughts?

dman’s picture

Thoughts? : turn some shit off! ;-B
Mate, that's a bit scary to be running on a shared server!
It may have nothing at all to do with your cron problems, but I would be surprised if your job wasn't buckling under the strain.
There's every chance you may have to invest in some more processing power. OR find a way to split, eg, your shopping area off from your community area. With some multisite magic you could probably make it seamless, but just have half the contrib modules loaded for each side of the site.
Couldn't say more until you'd reviewed your performance logs though. Eg through munin - but you probably don't have access to that on your host. See what their reporting tools can tell you.

lewisholden’s picture

But I'll try turning all the contributed modules off and see if that'll work. It's just thrown out a "Internal Server Error" so I've opened a support ticket.

Cheers

Lewis

Ben Howes’s picture

I had this issue come up on one of my sites when I was testing a new module I wrote... The problem cam up after a memory limit error, which caused the cron semaphore not to be deleted. I found that deleting it alone was not enough, I also had to clear the cache from the performance page then all was well!

I recommend clearing the semaphore (you can find this using phpmyadmin in the 'variable' table if you dont want to get the devel modules) then clearing the cache from the performance page.

Note that even if you don't have page caching turned on this makes a difference!

Good luck!

4v4l0n42’s picture

Drupal 6.14 running on bluehost.

I Tried all of these:
Specifically:

  • Cleared cache on admin/settings/performance.
  • Checked the size of the watchdog, sessions or acceslog tables and truncate (empty) if needed.
  • Searched in the variables table for cron_last and cron_semaphore and deleted these entries.
    DELETE FROM variable WHERE name="cron_semaphore";
  • Began to disable suspect modules (those that call hook_cron) one by one and try to run cron manually every time, but then I got to the point that only the essential modules were enabled:
    • aggregator
    • dblog
    • filter
    • node
    • ping
    • search
    • statistics
    • system
    • trigger
    • update
    • date_timezone
    • googleanalytics
    • mollom
    • user_stats
    • votingapi

Any less than this and the website will become unusable. I disabled all notifications and newsletters, but still got no luck.

Now, I tried killing the PHP process from the server using SSH, and according to top cron is not running.

To put it simply, drupal says cron is running, so I can't run it again. The server says cron is not running.

Any idea?

tiato’s picture

Using Drupal 6.20 and Bluehost I was able to get cron running again by deleting the rows 'cron_last' and cron_semaphore' then I cleared all caches and made sure my settings on bluehost were:

/usr/bin/wget -O - -q http://www.sandrinifoods.com/v2/cron.php

cron runs fine again and oddly enough seems to have 'fixed' an issue with the search module in that it was NOT generating an index in the DB, hope this helps others as it helped me!

wylbur’s picture

I was getting the following error message each time I tried to run Cron:

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

To get Cron running again I did the following:

Logged into myphpadmin
Emptied all cache tables in the database
Deleted the 'cron_last' entry in the variables table
Deleted the 'cron_semaphore' in the variables table

I restarted cron.php and it completed.

The Drupal version is 6.15
MySQL database 5.0.89
PHP 5.2.8

liza’s picture

it's 17 March 2010 --almost 3 years since this was first reported. I did disable UPDATE, delete the semaphore variable and clear cache. this solved the problem, but 3 years later we're running into this problem with UPDATE.MODULE and there's no fix to this?

dman’s picture

Well, to be fair, back in the 80s i'd sometimes see the error message "Cannot read from disk"
Today, the "same" error sometimes occurs still.
Does that mean there has been no improvement in the last 30 years?

This cron message can be caused by any number of things, but in general it means that something, somewhere, in any one of your modules, crashed or timed out without cleaning up after itself at some point when running a cron job.
A new module could be introduced tomorrow that would cause the same problem.

All the system can do is warn you that it's been broken. You'd need to do some tracing - like read the logs - to find out what it was doing when a failure happened. The error message is a *symptom*, a warning of an error condition, not a cause.
As long as a cause is possible (from *any* contrib code - or even from the server), the error message remains. Don't blame the messenger.

drinkypoo’s picture

I do blame the messenger. I should not have cron run fails without any useful error messages, which is what usually happens.

Drupal needs to have some more advanced tracing so that one can reasonably find out what is failing. Telling you that something somewhere failed is not very useful.

InterceptPoint’s picture

I've had the cron already running problem for several days on a new installation. I decided to try disabling the Update Module just to see what would happen. I disabled it. Ran cron manually and got the same error. My log tells me this error happened at 4:27 AM. So I turned the Update Module back on and saved the settings.

I then decided to go back and look at the log to see when the problem first showed up. So I filtered to cron problems in the log. And guess what? The log showed cron running successfully at 4:30AM. And so my cron if fine at least for now.

The mysteries of Drupal run deep.

sinasalek’s picture

Anyone having this issue, you might to install supercron much. Using this module you can put search module's cron under a different thread therefore it can't block the whole cron. No fix for search module's bug yet however!

sina.salek.ws, Software Manager & Lead developer
Feel freedom with open source softwares

sinasalek’s picture

Have a look at this pals : http://drupal.org/node/643474

sina.salek.ws, Software Manager & Lead developer
Feel freedom with open source softwares

bbenjamin602’s picture

Having the same issue as everyone else except mine appears to involve notifications and messaging. One thing to note is the messages are using mime mail with HTML input filter. Normal mail runs OK. When cron executes to run messages within the queue the following PHP watchdog error occurs which hangs cron.

require(/sites/all/modules/messaging/includes/messaging_destination.class.inc) [function.require]: failed to open stream: No such file or directory in /home4/mysite/public_html/sites/all/modules/autoload/autoload.module on line 33.

After that error you get:

Cron run exceeded the time limit and was aborted.
https://www.mysite.org/?/home4/mysite/public_html/cron.php

Using 6.16 and latest messaging and notifications modules. Tried clearing cash and semaphore. As long as there are Taxonomy notifications from the Forum to send out it will hang.

Frustrating!

drupalninja99’s picture

worked for me

nigelbabu’s picture

I think this error happens because cron started and failed for some reason and the cron_semaphore still remains in the database. For those of you folks who have this error even after deleting the cron_semaphore entry, that's because cron is still failing and one of your modules is creating a problem. Once I deleted my cron_semaphore entry and re-tried, the cron started back up for me. Looking at the apache error log though, I see the following entires

zend_mm_heap corrupted
[Mon May 31 14:52:42 2010] [notice] child pid 26445 exit signal Segmentation fault (11)
[Mon May 31 14:53:06 2010] [notice] child pid 26447 exit signal Segmentation fault (11)
[Mon May 31 15:25:10 2010] [notice] child pid 28208 exit signal Segmentation fault (11)
[Mon May 31 15:25:16 2010] [notice] child pid 28210 exit signal Segmentation fault (11)
[Mon May 31 16:05:07 2010] [notice] child pid 28360 exit signal Segmentation fault (11)
[Mon May 31 16:05:20 2010] [notice] child pid 26655 exit signal Segmentation fault (11)
[Mon May 31 16:08:17 2010] [notice] child pid 28760 exit signal Segmentation fault (11)
zend_mm_heap corrupted
[Mon May 31 17:25:06 2010] [notice] child pid 28757 exit signal Segmentation fault (11)
[Mon May 31 17:30:03 2010] [notice] child pid 29211 exit signal Segmentation fault (11)
[Mon May 31 17:30:03 2010] [notice] child pid 29700 exit signal Segmentation fault (11)

Perhaps the zend_mm_heap was the cause of the initial problem. Giving it a break and trying again somehow got the whole thing to work again. If someone still faces a problem, I'd encourage you to look at the apache logs to figure out what's going wrong.

herojig’s picture

My solution lay in module failure but no errors generated. your post got me in the right direction, thx!

Phoenix.Consultants.Nepal (www.phoenixstudiosnepal.com)

mugginsoft.net’s picture

This can occur if you exceed your allocated php memory limit during the cron run.
This may leave no trace in the Drupal log so you may need to run cron manually to verify.

The number of nodes indexed during a search has a big impact on memory usage during the cron.

sinasalek’s picture

The best solution is using supercron or similar modules. So you can run search index on different thread

sina.salek.ws, Software Manager & Lead developer
Feel freedom with open source softwares

mokko’s picture

Just to provide a link to the drush way of doing the same

http://alexanderallen.name/how-to-stop-hung-drupal-cronjobs

see also

http://groups.drupal.org/node/29794

sjtout’s picture

Tried suggestions from several posts, which eventually resulted in a memory related error message (deleted the message or would copy/paste it here). Upped the memory limit in php.ini (from 32 to 64 megs), and things worked again.

Side note, this originally started for me when trying to get LDAP integration going.

banghouse’s picture

Don't know if you guys have seen this or not but these instructions worked for me: http://drupal.org/node/360836

"Patience Luke, Let the object of your desire come to you." -- Obi Wan Kenobi

cristian.stoica’s picture

I confirm that the following procedure worked for me:
- disable update.status module
- flush all caches
- run cron (failed)
- enable update.status module
- flush all caches
- run cron (worked)
I suspect that in my case the script timed out when trying to check the updates. I suspect that the cron_semaphore variable can do the trick, too.

Lukas von Blarer’s picture

Resolved my issue. Thank you!

petek’s picture

I had the same problem "Attempting to re-run cron while it is already running." but it turned out to be a secondary error. None of the solutions worked for me, then I noticed that prior to the cron error I got:

"The total number of locks exceeds the lock table size" regarding my watchdog table.

I backed up this table and cleared it... then cleared the cache for good measure and cron runs fine now.

I'm not sure yet why I had so many recs in watchdog though...

remas2020’s picture

I don't mean to vent spleen but after working on this problem for over a month, and reading through every related post, a solution can't be found... and I'm not the only person dealing with this.

Problem: cron doesn't work with Drupal 5.3
Error: logs state "Attempting to re-run cron while it is already running." But it is *not* running.
"Solution": told to delete cron_semaphore (and any other cron*) in the variables table, and try again.

I've tried everything else from modifying common.inc, to completely uninstalling modules, to indexing only 10 nodes per run, to removing Update_status module, etc, etc. Yet cron continues to fail. And even when cron_semaphore has a value, the status report still tells me that cron has never been run.

The main problem lies with the fact that I, and many others, are new to drupal and can only take things so far. All I've seen are repeated answers stating to delete cron_semaphore but that is obviously not working for many of us... and many messages for further help go unanswered.

Can anyone who knows this software inside out offer any more insight? It's becoming a real struggle as I see over 2000 nodes (and counting) in the queue waiting to be indexed. No notifications are being sent out, and members are becoming less interested in a portal that isn't working correctly. Surely someone somewhere has found this same error and come up with a solution that has not yet been posted to the forums. Is it a particular module? Does it have to do with mysql itself? Is there some other code to add that might help figure out what is going on?

Any insight is very much appreciated...again sorry to be a little rough around the edges but the aggravation level is quite high right now.

Thanks.

Astutus’s picture

I had the similar problem but I can't found any cron_semaphore in variable table. I found cron_last otherway and deleted it but my problems isn't solved. After it I saw I have got a separately semaphore table which include a cron registry. I deleted it and clear the cache again and now everthing goes well.

It is similiar solution than upper but not with variable table.

wylbur’s picture

I have 'fixed' cron many times by deleting the cron_semaphore and cron_last records. By today that was doing no good. I'd never even seen a semaphore table before - until today! I cleared the entries in this table, and Cron ran successfully!

Using Drupal 7.23

Thanks Thanks Thanks!

rwilson0429’s picture

I was seeing the same message, Attempting to re-run cron while it is already running in the watchdog. And whenever I tried to run cron manually, I was getting the same message, Cron run failed. This was occurring in a D7 multisite environment. Only one of the sites was experiencing cron run problems. The problem turned out to be a schedule settings I setup in the Backup and Migrate module UI. I had set a Backup and Migrate schedule to Automatically backup my Entire Site (code, files & DB). Once I disabled this schedule, cron ran successfully.

ReggieW

davidneedham’s picture

Wow, I never would have expected backup and migrate to be causing this issue with cron, but you're absolutely right @rwilson0429. I disabled the scheduled backups in backup and migrate and cron started running normally again. Thanks for posting that solution here. For anyone else coming across this particular issue, leave a note about it in the backup and migrate issue queue.

--
David Needham
Agency & Community Training Manager | Pantheon

iebert’s picture

To rwilson0429: THANKS SO MUCH! You solved my problem as well.

Once I removed the "Entire Site" backup cron runs just fine. I still have the database and public files scheduled for backups, just the Entire Site backup is removed.

I also have a multisite and the problem never occurred for my primary domain, only the subdomain. Maybe the Backup and Migrate module is not set up to do Entire Site backups for subdomains?

In any case - thanks so much. After 6 hours of looking for a solution, your post finally solved my problem. And I can easily live without an Entire Site backup. Thanks!!!

Note: I also left a note about this experience in the backup and migrate issue queue (https://www.drupal.org/node/2402089).

285dinu’s picture

I tried delete cron_semaphore and cron_last from variable table
truncate cache and watchdog table
check all the module disabling after disabling check one one module enabling all the module work proper except search module when enable this module and any supporting module it return me error in common.inc file.
When I tried these all then run cron mannually it give me error in dblog file.
error 500 internal error with one
" DateTime::__construct() [datetime.--construct]: Failed to parse time string (@) at position 0 (@): Unexpected character in /home2/mitul28/public_html/includes/common.inc(1731) : eval()'d code on line 12."

I tried all the given solution below but still I get error "Attempting to re-run cron while it is already running."

Please help me it's very urgent and very important for my job also. please help me if any one.
Thanks in advanced.

285dinu’s picture

Hi friends,
I want to customize querystring type of url in normal url in drupal 6
Ex.
I have this kind of url

http://www.yourshoppingkart.com/women/bollywood-sarees-online?field_choo...

I want this kind of normal url
http://www.yourshoppingkart.com/Ysk/ysk-bollywood-replica

kenorb’s picture

Drupal 6
drush -y vdel cron_semaphore

Drupal 7
drush sqlq "TRUNCATE semaphore"

themic8’s picture

This did the trick.

My cron was always trying to re-run in the background several times a minute.

First I tried deleting the variables for cron. That did not work.

Once I truncated the semaphore table this reset the cron for me, in Drupal 7.

diegops’s picture

In my case I desabled PHP Filter, deleted cron_semaphore, cleared cache using phpmyadmin and run it. It worked. Enabled PHP Filter again and it run it.