Currently running Elysia Cron on a server and the message log is flooded the above message every couple of minutes in the logs, often it's ever minute, but not always, the longest time it goes without the error has been five minutes.
The cron is being called in the standard way from crontab, as follows:
* * * * * wget -O - -q -t 1 https://www.example.com/cron.php?cron_key={key}
The same issue is encountered on the development site on the same server under a different user, whose crontab contain:
* * * * * wget -O - -q -t 1 https://dev.example.com/cron.php?cron_key={key}
From the Elysia Cron statistics after the error appeared once: Last execution time: 2s (Shutdown: 0s) (Avg total: 4.86s, Max total: 463s)
A number of the max times for individual crons are over 60 seconds, specifically: apachesolr_cron (118s), field_cron (109s), support_cron (77s) and system_cron (438s); however the averages for all of these are under 10s. Of these, apachesolr_cron and support_cron are set to run every five minutes, and field_cron and system_cron are set to run hourly.
Worth noting that I've also tried deleting cron_semaphore and cron_last as suggested elsewhere, to no effect.
Any ideas?
| Comment | File | Size | Author |
|---|---|---|---|
| #11 | attemptingto_rerun_cron_message-1739972-10.patch | 491 bytes | majdi |
Comments
Comment #1
gotheric commentedThis seems a locking problem in you installation (maybe some other module that does something strange to it?)
First, try using the advanced install (use "https://www.example.com/sites/all/modules/elysia_cron/cron.php" instead of "https://www.example.com/cron.php"), see INSTALL.TXT for more info.
If it doesn't work try installing latest DEV version (that has some differences in locking system).
Let me know if one of these methods works.
Comment #2
hephaestus commentedThanks gotheric, I've made the switch to the advanced install and will see how it goes.
We had been using the file_lock module, although we removed this a while back, not sure if this could cause any issues? I assume it's not the same locking system.
Comment #3
hephaestus commentedThis seems to have resolved the issue, thanks for the advice.
Comment #4
rosk0I have same problems but cron tasks is executed through
drush elysia-cron.Comment #5
gotheric commented@RoSk0: Try updating to DEV version (that has a better support for Drush), or wait for next stable release (soon, i hope)
Comment #6
regilero commentedhere is a (very) simple patch on core (includes/common.inc) to comment the watchdog entry.
Note. It was too simple, this first version of patch is wrong.
Comment #7
regilero commentedThe right patch.
Comment #8
roeneman commentedOld post, but new suggestion:
To possibly solve above issue, may I suggest to change line 997 of latest dev:
"if (!lock_acquire('cron', 240.0)) {"
into:
"if (!lock_acquire('cron', 240.1)) {"
So the difference is in the "240.1". What it does is setting the lock acquire expire time 0.1 higher then drupal_cron does. Because when it is the same time, db_update will return 'FALSE' (resulting in denying the lock) when trying to extend the lock for Elysia cron.
From debugging I discovered that in my system - at irregular times - the expire time set in lock_acquire (in /includes/lock.inc) is the same for drupal_cron calling lock_acquire as the subsequently Elysia_cron calling lock_acquire. My system is apparently so fast/lean that it sometimes handles the 2 calls in less then 1 microsecond.
The expire time is done in microseconds, apparently the most precize timing PHP currently offers, so a change to the lock_acquire function to for instance nanoseconds can't be the solution.
So therefore the suggestion to add 1 microsecond to the timeout argument in Elysia cron when calling lock_acquire. Yes, deliberatly slowing down my system (a little), but for that have at least the cron run running.
Sorry for not beeing able to write up patches .... hopefully someone will translate my suggestion into a patch.
Thanks, Roeneman
Comment #9
drewkeller commentedI was all set to comment out the annoying message, but though I would try Roeneman's suggestion first. It worked for me. Most of the time my website has nothing to do, so I guess the job finishes too fast.
Comment #10
majdi commented#8 solve my problem thanks roeneman
Comment #11
majdi commentedBased on #8 here is the patch
Comment #12
majdi commentedComment #13
jelo commentedI manually applied the change in line 905 of version 7.x-2.1. Fixed the issue for me!
Comment #14
jelo commentedWell, and after 15 minutes it is now back displaying the warning every 5 minutes. I will try the other suggestion switching to the elysia cron call...
Comment #15
akshita commentedAny solution please for drupal 7?
cron 05/07/2015 - 09:41 Cron run completed. Anonymous (not verified)
cron 05/07/2015 - 09:41 Attempting to re-run cron while it is already running. Anonymous (not verified)
cron 05/07/2015 - 09:41 Attempting to re-run cron while it is already running. Anonymous (not verified)
job_scheduler 05/07/2015 - 09:41 Finished processing scheduled jobs (0 sec s, 1 total,... Anonymous (not verified)
cron 05/07/2015 - 09:41 Attempting to re-run cron while it is already running. Anonymous (not verified)
Comment #16
vinodkrishnan commentedIf you want to remove the lock set the column running in elysia_cron table to 0 for your cronjob
Comment #17
juankvillegas commentedI tested #11 in 7 different sites and the problem dissapeared in all of them.
Comment #18
kala4ekNot sure about the solution in #11, sounds like some kind of crutch.
The question is, why core cron is running at the same time with Elysia cron?
Comment #19
joelpittetMaybe that settings is still checked to run poormans cron every 3 hours? It's kinda hidden in the collapsed field under settings?
Comment #20
kala4ekGuys (who faced with such problem), could you check please this setting?
Also, how did you launch the cron? Via drush or cron.php file?
Does it reproduced for 7.x-2.3 versions too?
Comment #21
juankvillegas commentedI'll share how I set up Elysia Cron in my sites in case it helps to find out the issue... but with the newest version of Elysia Cron (7.x-2.3), I haven't applied #11 patch and I haven't seen the error any more. So I think it is fixed now.
I do not set up cron to run every minute as is suggested by the module. I set up all my sites to run once per hour. As I have a lot of websites in my server, I have one website's cron running on minute 1, other on 3, 6, 8, 11, 13... I do this because I noted that some heavy tasks, like Backup and Migrate, where running at the same time for several websites and some times it took my server down.
About the configuration mentioned by kala4ek, I set it up to 12 hours, just in case something happens with my cron jobs at least it will keep doing some tasks while I found the issue, but it really never happens, I think I could totally disable it and there shouldn't be any difference. I mean, I think it checks when was the last time the cron was executed, and it was always executed less than 12 hours ago.
I split my cron jobs in groups. 1 group for each heavy task and the default group for all the easy tasks.
As I mentioned in #17, I applied the patch from #11 for a lot of websites, I can't remember how many websites, but at least 30 websites and it fixed the issue in all of them, but as mentioned at the beginning of this answer, I haven't needed the patch any more with the new version.