Magento2: cronjob tasks defined within 'default' group are not properly running

Created on 10 Dec 2015  路  13Comments  路  Source: magento/magento2

I'm trying to define a cronjob for a custom module but noticing some issues:

  • It seems that third-party cronjobs are only scheduled once, when the cache is flushed. When the scheduled ./bin/magento cron:run runs every minute, the first time the cache is flushed it picks up all of the third-party module cronjobs, and runs them on the next execution.
  • After the first run, it doesn't seem as though these third-party modules are scheduled for a second run, ever. Until the cache is flushed again.

    • Is this perhaps related to cron group? I noticed that items in the default cron group never get rescheduled, but it seems that items in the index cron group do (at least items from core code).

    • Disabling the cache doesn't help.

    • Even if cache is disabled, the third-party modules never get registered.

    • Even if cache is disabled, iff a ./bin/magento cache:flush is run, all of the items in the default group do get scheduled. This leads me to believe that either that cache is not getting properly disabled, there is a bug in the caching system, and/or there is some sort of intricacy with how the cache actually works.

  • What is the purpose of running php update/cron.php if we are already running ./bin/magento cron:run, and what is the difference between the two? I'm pulling info from devdocs http://devdocs.magento.com/guides/v2.0/config-guide/cli/config-cli-subcommands-cron.html#config-cli-cron-bkg
Ready for Work needs update bug report

All 13 comments

/update/cron.php is for the Component Manager and System Upgrade. It's what kicks off the update/upgrade processes. I imagine it also runs enable/disable and uninstall as well. /update/cron.php does not run indexers or other scheduled jobs like e-mail, site map, etc.

I was noticing some similarly unexpected behavior with adding a new task to the default cron group. I tried to create a job that would run every minute, but on the default group it only executed around every 15 minutes, and I wasn't seeing pending jobs in the cron_schedule table like I was expecting.

I ended up creating my own cron group with:

        <schedule_generate_every>5</schedule_generate_every>
        <schedule_ahead_for>19</schedule_ahead_for>
        <schedule_lifetime>14</schedule_lifetime>
        <history_cleanup_every>10</history_cleanup_every>
        <history_success_lifetime>60</history_success_lifetime>
        <history_failure_lifetime>600</history_failure_lifetime>
        <use_separate_process>1</use_separate_process>

and a job with <schedule>*/5 * * * *</schedule> to get it to execute my cron job every 5 minutes. It kicks off the job every 5 minutes, but it typically doesn't create the cron_schedule record until a couple minutes before it executes it, and in some cases it creates the record after it is scheduled.

schedule_id job_code    status  messages    created_at          scheduled_at        executed_at         finished_at
17675       my_cron_job success NULL        2015-12-18 15:24:10 2015-12-18 15:25:00 2015-12-18 15:25:13 2015-12-18 15:25:13
17683       my_cron_job success NULL        2015-12-18 15:29:13 2015-12-18 15:30:00 2015-12-18 15:30:14 2015-12-18 15:30:15
17691       my_cron_job success NULL        2015-12-18 15:35:11 2015-12-18 15:35:00 2015-12-18 15:36:15 2015-12-18 15:36:17
17715       my_cron_job success NULL        2015-12-18 15:41:15 2015-12-18 15:45:00 2015-12-18 15:45:15 2015-12-18 15:45:17
17725       my_cron_job success NULL        2015-12-18 15:47:09 2015-12-18 15:50:00 2015-12-18 15:50:15 2015-12-18 15:50:17

I managed to get it to run every 5 minutes, but the whole scheduling bit has me confused, because I'm not seeing it schedule jobs ahead for the next 19 minutes.

@xcomSteveJohnson this shouldn't be labeled a question, it's a bug. a pretty high priority one for that matter :)

@markoshust They don't let me label anything...

Sorry -- I meant to reference @okorshenko, not you :)

I am experiencing the same issue using Magento 2.0.1 CE

@werdlv could be because this ticket is still in 'open' status and not resolved ;)

We have created MAGETWO-48243 to track a fix for this.

@markoshust

  • Schedule for 'default' Cron group is generated once per 15 minutes while schedule for 'index' Cron group is generated every minute. Is it possible that your task is scheduled to run too soon?
  • Cron is currently using 'generic' cache for scheduling, which cannot be disabled. This issue will be investigated in the scope of MAGETWO-48243. Update: generic cache would be the appropriate cache for scheduling so it's behavior won't be changed.
  • 'Generic' cache uses var/cache which is shared with other cache types by default. So cache:flush will flush 'generic' cache by default.

@markoshust any response to @eddielau's comment?

@markoshust closing as non-responsive.

Magento 2.1.1 - custom cron job for.third party module was scheduled when i run 麓cron:run麓 two times. After first it was only some magento default. Executing was possible after third command run. It was set for every minute.

@bartek9007
I've seen some odd behavior with how tasks are scheduled ahead. Noticed in v2.0.6 in the last few weeks. In my instance of trying to get a 3rd party extension to execute a cron task every minute I was noticing that it would only schedule ahead one execution of the task. With the default cron group set by default to generate scheduled tasks every 15 minutes I was only seeing the task execute every 15 minutes. As a workaround I was able to change the frequency of the Generate Schedules Every field in the admin to every 1 minute and since it was building the schedule every minute, it would execute every minute.

I think there may be some issues with how tasks are scheduled ahead, since I'm only seeing it schedule ahead one iteration of a task that it should be scheduling ahead many more.

Was this page helpful?
0 / 5 - 0 ratings