Skip to content

cronjob tasks defined within 'default' group are not properly running #2672

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
markshust opened this issue Dec 10, 2015 · 13 comments
Closed
Labels
bug report Issue: Ready for Work Gate 4. Acknowledged. Issue is added to backlog and ready for development Progress: needs update

Comments

@markshust
Copy link
Contributor

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
@ghost
Copy link

ghost commented Dec 10, 2015

/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.

@mttjohnson
Copy link

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.

@markshust
Copy link
Contributor Author

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

@ghost
Copy link

ghost commented Jan 8, 2016

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

@markshust
Copy link
Contributor Author

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

@jsakars
Copy link

jsakars commented Jan 22, 2016

I am experiencing the same issue using Magento 2.0.1 CE

@markshust
Copy link
Contributor Author

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

@mazhalai
Copy link
Contributor

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

@mazhalai mazhalai added the Issue: Ready for Work Gate 4. Acknowledged. Issue is added to backlog and ready for development label Jan 22, 2016
@eddielau
Copy link
Contributor

@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.

@mazhalai
Copy link
Contributor

mazhalai commented Mar 2, 2016

@markoshust any response to @eddielau's comment?

@mazhalai
Copy link
Contributor

mazhalai commented Mar 7, 2016

@markoshust closing as non-responsive.

@bartoszkubicki
Copy link

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.

@mttjohnson
Copy link

@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.

magento-engcom-team pushed a commit that referenced this issue Jun 9, 2018
…hql-ce-83

Engcom 1833 magento graphql ce 83
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug report Issue: Ready for Work Gate 4. Acknowledged. Issue is added to backlog and ready for development Progress: needs update
Projects
None yet
Development

No branches or pull requests

8 participants