3

We're only seeing this for projects on one specific server (running Centos7; using chrony; PHP 5.6.21). We are NOT seeing this for projects on our other server (running Centos6; using ntpd); Working theory is that we should go to ntpd on Centos7. Has anyone else run into this?

The problem: a Scheduled Job configured to run daily - runs exactly every 25h:

2016-05-21 15:04:51 
2016-05-20 14:04:17 
2016-05-19 13:04:41

EDIT: system crons (Drupal and CiviCRM) run hourly - on 03 and 04, respectively - and I've confirmed those jobs that are scheduled to run 'always' indeed execute every hour.

1

3 Answers 3

3

I don't know if this is the case here, and it seems more regular than my experience, but my coworkers and I have seen cron jobs walk fairly regularly. (We're more commonly using Ubuntu 14.04 or 12.04, however.)

The usual issue I see is the following with a daily scheduled job:

  • cron run starts at 1:00:00
  • there are a bunch of things to do, so it gets to the daily job at 1:00:20
  • the next day at 1:00:00, cron runs again
  • there's less to do, so it gets to the daily scheduled job at 1:00:10
  • being "daily", the scheduled job checks to make sure its previous run was more than one day ago, and that check fails since it was 23 hours, 59 minutes, 50 seconds ago
  • the scheduled job executes the next time cron runs

In my experience, that would normally make the scheduled job walk one cron interval (usually 5, 6, 10, or 15 minutes) rather than an entire hour. However, if you only have the cron job running hourly, that would explain your phenomenon exactly.

Unfortunately, there's no way to guarantee that a scheduled job will get run at a precise time each day unless you have a separate cron job to run the single scheduled job. However, reducing the cron interval will mean that when the schedule job does walk, it'll take smaller steps.

(Side note: this situation is why I always have the scheduled reminders job run hourly rather than daily. Otherwise, the scheduled job might walk all the way to 11:00 pm, potentially reminding people about the next day's event after the recipients have gone to bed.)

UPDATE: As Karin describes below, this was addressed in 4.6.3, so the later 4.6.x releases all fix this. However, some changes introduced in 4.7 had the result of undoing this. The relevant issue is CRM-18671 for describing what's going on.

3
  • Thanks Andrew! I'm hesitant to move this recurring contributions job from daily to hourly - though I understand that would in all likelihood reduce the speed at which these jobs are walking. Commented May 24, 2016 at 19:22
  • So your update explains why this is all working for us on the hours - exactly - for all our 4.6.x-es. Thanks for creating the JIRA issue: issues.civicrm.org/jira/browse/CRM-18671 Commented May 24, 2016 at 19:24
  • 1
    Worth noting, the CronPlus extension (lab.civicrm.org/extensions/cronplus) purports to alleviate this problem.
    – TwoMice
    Commented Aug 6, 2019 at 18:25
2

This extension might solve this issue: Cron Plus

1

This may actually not be related to Centos7 vs Centos6 but due to the fact that the project in question is still on 4.4 LTS - Looks like this was addressed in 4.6.3: https://issues.civicrm.org/jira/browse/CRM-16276 - thanks @Allan Shaw!

3
  • Ooh, I didn't know about this fix. It's for 4.6 only, however--that trick of looking at the hour or day is no longer in effect for 4.7: github.com/civicrm/civicrm-core/blob/…
    – Andie Hunt
    Commented May 24, 2016 at 18:23
  • I do recall seeing this a few years ago but not going down the rabbit hole to diagnose, etc.
    – Joe Murray
    Commented May 24, 2016 at 19:10
  • @AndrewHunt - shoot I thought I was onto something! :-) Commented May 24, 2016 at 19:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.