If you run `drush crun` also disabled cron jobs are executed. (If you execute cron from backend interface only enabled cron jobs will be executed.)

ultimate_cron.drush.inc // drush_ultimate_cron_cron_run

    // Run all jobs.
    $jobs = CronJob::loadMultiple();

    /** @var CronJob $job */
    foreach($jobs as $job) {
      if ($force || $job->isScheduled()) {
        $job->run(t('Launched by drush'));
      }
    }

Should be something like that.

    // Run all jobs.
    $jobs = CronJob::loadMultiple();

    /** @var CronJob $job */
    foreach($jobs as $job) {
      if ($force || ($job->status() === TRUE && $job->isScheduled())) {
        $job->run(t('Launched by drush'));
      }
    }
Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

frantisekivanko created an issue. See original summary.

frantisekivanko’s picture

frantisekivanko’s picture

frantisekivanko’s picture

Issue summary: View changes
c.nish2k3’s picture

Status: Active » Needs review
Berdir’s picture

Status: Needs review » Needs work

Note that it's easy to avoid this by using the standard core drush command to run cron: drush core-cron. This works fine, uses the cron service and respects the status.

I'm not sure if we shouldn't just remove this method completely and just keep the option to run one specific cron job.

It's also missing other things like processing queues (unless queues are exposes as cron jobs), setting the last run status and so on.

maosmurf’s picture

Thank you for the patch!

The ultimate_cron setup with exposed queues works great for us.

Note that it's easy to avoid this by using the standard core drush command to run cron: drush core-cron.

Wouldn't this make the whole module more or less useless?
We love ultimate_cron for 2 reasons:
* multiple, independent tasks per module (not limited to hook_cron)
* flexible configuration of schedules

Berdir’s picture

No, it does not, the module replaces the service that does the cron processing, it works just fine if you use drush core-cron.

kala4ek’s picture

We launching cron via drush crun and disabled jobs executes as well.
Guess it's time to port Elysia cron.

jefuri’s picture

@Berdir wouldn't relying on the core-cron make custom options not available to use that cron-run does support? Like threads and stuff.

wouters_f’s picture

This is still happening so it seems.

jantoine’s picture

I'm running into a related problem that I found an issue for here: #3163408: Ultimate Cron Timezone issue as cron executed both in IST and UTC. It's not the same issue, but it's an issue with @Berdir's workaround suggestion, to use core's cron, in #6. The issue is that core's cron is running processes for both the local timezone and UTC when executed via drush. Once this issue is resolved, perhaps @Berdir's suggestion would work, but as it stands, this is not a workable solution for me.

wesleymusgrove’s picture

?

wesleymusgrove’s picture

I have disabled a cron job using the admin interface (/admin/config/system/cron/jobs) that was originally running every 15 minutes, however it is still being executed months after I disabled it. All cron tasks are being executed by an Acquia scheduled job that is running drush cron. I thought disabling a specific custom module's cron task in the admin interface would prevent its hook_cron hook from getting executed?

Why does this Ultimate Cron documentation say NOT to use drush cron and instead use drush cron-run?

Note: Make sure not to use drush cron as you would do when not using Ultimate Cron.

When I tried using drush cron-run it dumps out message that says:

Running all cronjobs is not supported by Ultimate Cron's cron:run - please use Drupal Core's core:cron command!

When I run drush core:cron I can hit breakpoints inside the hook_cron function for the job that I have disabled in the admin interface. I have drush cr'd. Why is this hook still being hit if the job is disabled?

Isn't the status enabled/disabled check proposed by this patch already being done in the isScheduled function?

See ultimate_cron\src\Entity\CronJob.php

/**
   * Check job schedule.
   */
  public function isScheduled() {
    \Drupal::moduleHandler()->invokeAll('cron_pre_schedule', array($this));
    $result = $this->status() && !$this->isLocked() && $this->getPlugin('scheduler')
        ->isScheduled($this);
    \Drupal::moduleHandler()->invokeAll('cron_post_schedule', array($this));
    return $result;
  }
wesleymusgrove’s picture

I think my issue is that my custom hook_cron implementation processed a Drupal queue. It _wasn't_ executing a disabled cron job. However after it finished running all the enabled cron jobs, it then started processing all the Drupal queues. So it appeared that my cron hook was running, but really it was this code doing it in ultimate_cron\src\UltimateCron.php

    // Run standard queue processing if our own handling is disabled.
    if (!$this->configFactory->get('ultimate_cron.settings')->get('queue.enabled')) {
      $this->processQueues();
    }

I didn't realize it was processing Drupal queues by default. Looks like I need to override the default queue processing for my custom queue that I'm trying to disable here: /admin/config/system/cron/settings

a.milkovsky’s picture

This issue is outdated, as only a single job can be passed to the drush command `cron-run`.