When invoked via drush cron-run, a background process is started through an http request.

It is desirable not to use an http request, but to run the job in the current process. This allows for different php configuration (memory, etc.) especially for cron jobs, and eliminates an unnecessary hog of a webserver process.

Notes to self:
Explicitely state cli behavior to maintain backwards compatibility.

New feature, e.g.:
drush cron-run node_cron --cli

Should run process immediately without issuing an http request. Locking needs to be properly in place, as co-existence with the cron run from http is necessary.

drush cron-run all --cli
Should run all scheduled cron jobs, each job in a new drush instance, e.g. system("drush cron-run node_cron --cli &")
Crossplatform considerations should be made.

Running jobs in a serial fashion should not be directly supported by this, but handled by separate modules like Ultimate Cron Serializer.

Comments

gielfeldt’s picture

gielfeldt commented

Notes:
Use background process to run "drush" in order to take advantage of load balancing features from drush?

gielfeldt’s picture

gielfeldt commented

New drush CLI support committed to 7.x-1.x-dev (use git or wait for tarball build)


Examples
Run node_cron immediately without http request
drush cron-run node_cron --cli

Run node_cron immediately without http request, but check if job is scheduled to run
drush cron-run node_cron --cli --check-rule

Run all cron jobs that are scheduled to run, using a separate drush request per job (*nix only!)
drush cron-run all --cli

Run all cron jobs that are scheduled to run, using a separate drush request per job, and double check schedule on subrequest (*nix only!)
drush cron-run all --cli ---check-rule

NOTE: When using drush to run cron jobs, the load balancing features from Background Process are unavailable. The jobs is executed on the server where the drush command is run.

To replace Drupals default crontab (wget ....) use:
* * * * * drush cron-run all --cli --check-rule

@manu manu: Could you please provide some feedback on how this works for you?

Thanks

gielfeldt’s picture

gielfeldt commented
Status: Active » Needs review
manu manu’s picture

manu manu
Primary language French
Location Aix-en-Provence
commented

Hi Gielfeldt,

Thanks very much for working on this issue, I will checkout and test it this week.

manu manu’s picture

manu manu
Primary language French
Location Aix-en-Provence
commented

Hi gielfeldt,

At first look, it's working well in a separate test setup!

I will checkout it into our main dev branch and test it in the long run this week.

gielfeldt’s picture

gielfeldt commented

@manu manu: Any verdict yet?

manu manu’s picture

manu manu
Primary language French
Location Aix-en-Provence
commented

Hi gielfeldt!

This is a quick reply during a family dinner;-) every thing is wonking fine, I even switched it to prod. i will provide more feedback these days, sorry for the delay!

gielfeldt’s picture

gielfeldt commented

Hi

No rush, I was just curious. Bon appetit. :-)

/Thomas

manu manu’s picture

manu manu
Primary language French
Location Aix-en-Provence
commented

Hi Thomas,

Thanks and happy new year!

Its works great, I had no problem during these last 10 days.

Right now I've only tested drush cron-run all --cli as it mets my immediate needs.

Its a real pleasure to be able to read logs for each job.

Just a little suggestion: If cron run --cli is intend to be run with crontab, why not output only if -v or --verbose is set?

I'll test the --check-rule option soon.

Thanks again for this module and for implementing these features, thats great.

gielfeldt’s picture

gielfeldt commented

Hi

Sounds great.

Thanks for the suggestion regarding output -v. I'll consider this and look into it.

Btw, I've also been testing this myself, and on my system, it crashed after a while, if I didn't specify --check-rule for drush cron-run all --cli. I'm not sure why this happens, but I suspect some kind of fork bombing takes place, even though I haven't been able to identify it. I might end up making --check-rule implicit when using all

Thanks for testing it.

/Thomas

gielfeldt’s picture

gielfeldt commented

Hi manu

I've concluded that my system crashes was not because of Ultimate Cron. So if you have not experienced any problems with it since last time, I will consider this feature ready for the next release.

/Thomas

manu manu’s picture

manu manu
Primary language French
Location Aix-en-Provence
commented
Status: Needs review » Reviewed & tested by the community

Hi Thomas,

I had once some segfaults, but it was a problem in Search API.
I really stress up my setup, with some cron jobs running every minute, some jobs eating 50% of 8GB ram.. Every thing is running fine so I'm more and more confident in these new features!

Don't hesitate to ping me for more tests or feedback

gielfeldt’s picture

gielfeldt commented
Status: Reviewed & tested by the community » Patch (to be ported)
gielfeldt’s picture

gielfeldt commented
Status: Patch (to be ported) » Fixed

Committed to 6.x-1.x-dev.

gielfeldt’s picture

gielfeldt commented

Committed to 6.x-1.x-dev...

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

michee.lengronne’s picture

michee.lengronne
Primary language French
commented

Hello,

I have another question. Is there a way to avoid ultimate-cron writing in /var/mail/root when everything works fine ?

gielfeldt’s picture

gielfeldt commented

I believe you can redirect stdout to /dev/null.

manu manu’s picture

manu manu
Primary language French
Location Aix-en-Provence
commented

Here is an example:

*/5 * * * * drush -r /var/www/project_name/html cron-run --cli all > /dev/null 2>&1

michee.lengronne’s picture

michee.lengronne
Primary language French
commented

I am not sure that my cron run well, because nothing change on the cron interface.

The crons times in the table are not updated. In the status report, the cron is updated correctly but the other informations not (out of date modules, etc...). Is it a normal behaviour or not ?

gielfeldt’s picture

gielfeldt commented

Lets continue this discussion in a new and more relevant thread. Can you create a new issue describing the actual problem in detail?

Thanks

michee.lengronne’s picture

michee.lengronne
Primary language French
commented

Ok, that's done.

hassan2’s picture

hassan2 commented

I have completely replaced my wget cron job with this one. it is fantastic. Thank you to the programmer.
This is the command i have used just incase anyone needs it.

drush -r /home/myhomepage/public_html/ cron run --cli all ---check-rule > /dev/null 2>&1

Thank you again

gargsuchi’s picture

gargsuchi commented
Issue summary: View changes

I upgraded the module to version
version = "7.x-2.0-beta4"
and it seems that this drush option has been removed.

Can this please be added back.

gielfeldt’s picture

gielfeldt commented

The responsibility of launching background processes (through http or drush) is being moved to the Background Process module. In Background Process 2.0 (work in progress) it will be possible to launch the individual cron jobs through Drush like described in this thread.