While debugging some problems with cron, I realized that the watchdog() call in drupal_cron_cleanup() can cause problems in some cases. The drupal_cron_cleanup() function is called at the end of a cron run, including in situations where cron failed due to a PHP timeout error or other serious problem. In that case, things might be in a very weird state. The watchdog() call might therefore lead to fatal PHP errors of its own. (The particular case where I saw this occur is if you have Syslog and Views UI modules enabled, but I'm sure there are others.)
Since the most important thing that drupal_cron_cleanup() does is delete the cron semaphore, my solution was just to move that up to the top of the function. That way if things fail catastrophically later on, at least the semaphore is deleted, and cron is not locked up for the next hour. (If you look through the forums, they're full of people who are getting cron locked up for an hour and need to delete the semaphore by hand in the database, etc. I don't think this will solve all of those problems, but it should help in some cases -- and certainly it doesn't hurt!)
Patch is attached. I also modified the message that watchdog() prints in this case, since it simply isn't true that the only way for the semaphore to be locked is the if the PHP script execution time was exceeded. Certain other types of errors (e.g., calls to nonexistent functions) during the cron run can trigger this too.
| Comment | File | Size | Author |
|---|---|---|---|
| drupal_cron_cleanup.patch | 1.13 KB | David_Rothstein |
Comments
Comment #2
lilou commentedSee: #335122: Test clean HEAD after every commit and http://pastebin.ca/1258476
Comment #3
dries commentedDavid, what is not clear is why not releasing the semaphore is that problematic? I think it would be good if we could be a bit more explanatory as to why it is important.
Comment #4
jackspiv commentedHi,
I have an honest disclaimer. I am in the wrong place here by a long shot
I'm still on v 5.12 (I just checked the version a bit too late...)
Wondering if you could either take a moment out or point me elsewhere to a similar serious discussion about fixing the problem for 5.x? All of the fixes that I've found are just shutting off the semaphore. When I restart it, I have the same problems a week or two later. Has this ever been solved for the earlier versions?
I am one of those users having trouble with cron
followed all I can find in the forums and issues
deleted cron_last from the variables table for each one of 4 prefixed tablesets in a multisite install (one codebase 4 prefixed table sets in a single database)
set semaphore=false (with correct syntax) in common.inc.
Cron now runs correctly on all but one site. Having no luck with that one.
As far as I know I did same sequence on each.
Thanks in advance for any attention you might spend on my behalf.
Jack
Comment #6
filijonka commentedCan anyone explain why this hasn't been taken care of?
Comment #7
sdstyles commenteddrupal_cron_cleanup.patch queued for re-testing.
Comment #9
berdirClosing as duplicate of #1775488: drupal_cron_cleanup is not converted to lock.