Run Now… Sometimes does, sometimes doesn’t

  • Morning John,

    Our sites’ are configured the same in terms of WP_DISABLE_CRON = True and all have a cronjob set in cPanel (or host equivalent) to trigger wp_cron either via WP_CLI or direct scheduled at least twice an hour, but frequently per minute. The system cron schedule is only important to illustrate that the shortest frequency between wp_cron execution is 1 minute.

    What I experience,
    On some sites selecting Run Now on a scheduled task in WP Crontrol appears to trigger the job immediately – as in at whatever second it is past the minute, say 12:45:23 – which is what I’m expecting. When the page refreshes, it has begun running.
    Whereas, on other sites, Run now creates a backdated version of the scheduled task, on the page refresh it then appears top of the queue and the system waits until system cron triggers the wp_cron action.

    I’ve been having this issue across our sites since I’ve started working with WP that has WP Crontrol and I just can’t seem to narrow down if there’s a setting or configuration I’m missing.

    I initially thought that it must be that the site still is running wp_cron by page visit/refresh. But on each I have confirmed that DISABLE_WP_CRON is true in wp_config.php.

    I notice in Viewing error output when using “Run Now” you state

    Thanks for the report. I’ve tried very hard to ensure that when you use “Run Now” in WP Crontrol that it runs the event in the same manner as it runs when scheduled normally (some other cron management plugins simply call the action for the event which means the context for the request is incorrect). What happens behind the scenes is it schedules an event in the past and then immediately spawns the cron event runner.

    which is what I expect to happen.

    Are you able to shed any light on why some of the sites just create the queued job and wait for system cron?

    Cheers

Viewing 3 replies - 1 through 3 (of 3 total)
  • Thread Starter breckf

    (@breckf)

    I just noticed that in the latest version 1.15.0 there is also now another action type on the backdated event that gets scheduled to run. Not sure if this was always there but I don’t recall seeing it.

    The extra action is Delete All 2.

    Plugin Author John Blackbourn

    (@johnbillion)

    WordPress Core Developer

    When you click Run Now and WP Crontrol schedules the event in the past, it also calls the spawn_cron() function which causes the cron event queue to be processed immediately. This is how the event usually runs immediately. However if you’ve got high frequency cron events (ie. once per minute) or long-running cron events there’s a chance that any of the various guard conditions inside this function will result in the queue not being processed, in order to avoid duplicate events, concurrent processing, etc. The queue also won’t be processed more often than once every WP_CRON_LOCK_TIMEOUT seconds, which is by default 60.

    Unfortunately there’s not a lot that WP Crontrol can do about this. The spawn_cron() function doesn’t return any useful error messages, and in practice I’ve found that by the time you see the problem, have a think about it, and reload the page, the event has been run anyway. I have thought about bypassing spawn_cron() and triggering the underlying request to wp-cron.php directly, but that involves duplicating more of the internal logic which I wanted to avoid as much as possible as it increases the maintenance overhead each time there’s a new release of WordPress to make sure it still operates in the exact same way that WordPress core does. But I think I might need to do this.

    The “Delete All {n}” action appears when there’s more than one event scheduled with the same hook name. This allows you to clear out duplicates.

    Thread Starter breckf

    (@breckf)

    Thanks John. I’ll look into that timeout and the spawn job on the client sites.

    Irritatingly I know the site I was working on today has the croon set to run every minute and it spawns immediately. So I assume it’s not that.

    But I had wondered previously if there was something like that in place as on other sites when I would try to manually trigger the cron from shell on some sites it would not allow it to trigger for a seeming period. I had wondered if doing_cron or some such was still set and preventing a new spawn.

Viewing 3 replies - 1 through 3 (of 3 total)
  • The topic ‘Run Now… Sometimes does, sometimes doesn’t’ is closed to new replies.

Tags