Ultimate cron vs Elysia cron

It's been quite awhile since I looked at Elysia Cron in detail, but the main difference is probably (listing Ultimate Cron features):

* True parallelization of jobs (including queues) vs serial processing of "channels"
* Load balancing in multiple server setup
* Aims to work out-of-the box for all features and everything configurable from within Drupal, with no need for server sysadm know-how (well except for the cron syntax).
* Extensible (hook_cron_alter(), hook_cron_schedule_alter(), etc.)
* Multiple rules per job (if you need a special rule, that cannot be expressed through one cron syntax)
* Self-healing capabilites for stalled jobs.
* Controlling/throttling of queue processing through Ultimate Cron Queue Scaler (dev).
* (Re)serializing jobs if needed through Ultimate Cron Serializer (dev).

Note: warning may be biased, as the differences mentioning above were the features I lacked in Elysia Cron.

Now for the main similarity:
I actually started out by using Elysia Cron for the project that I created the original Ultimate Cron module for. However it didn't fit my needs, and when attempting to add what I neeeded, I ended up doing such as big rewrite, that it warranted a new module, also taking in to account that the goals of the Elysia and Ultimate are different. This also means that being inspired greatly by Elysia Cron, 3rd party modules using hook_cronapi() for Elysia Cron should be possible to use with Ultimate Cron. I'm currently trying to work out with the maintainer of a common cronapi() format and perhaps propose this for Drupal 8.

Yes, a new release should be made soon. I'm was currently working on it, but put on hold due to lack of time. I'll see if I can get it done real soon.

I would always recommend setting up a cron in linux instead of using poorman's cron, if this is possible, as this is more stable. However, there are some improvements in Ultimate Cron's poorman's cron over the core one. It launches the cron scheduler in a background process, which keeps itself alive, so you just need one page visit to trigger it, and then cron is running. The other benefit of launching the scheduler in a background process, is that it cron runs don't take up the end users time.

This poorman's cron process can die of course, in cases of server restarts, broken code during updates, etc., and then you need another page visit to relaunch it. So it's a judgement call I guess, depending on how rarely "rarely" is.

When running in poorman's cron mode, Ultimate Cron works only if a visitor has triggered the cron. Just like Drupal without Ultimate Cron. However, it's should be necessary to repeatedly visit the page to launch cron, like it is in a regular Drupal setup, because the poorman's cron from Ultimate Cron is a background driven process.

If setting up a linux crontab (e.g. wget * * * * * http://example.com/cron.php) you can disable the poorman's cron. There's a checkbox for this on the Ultimate Cron settings page.

In most cases, Ultimate Cron will work out-of-the box using the poorman's cron method, even if no linux crontab has been setup.

As of D7 the poorman's cron is the default way to run cron, why this is enabled upon installation of Ultimate Cron.

And yes, Ultimate Cron bypasses the regular cron and parallelizes everything.

1.) Yes. Remember to use "* * * * *" (every minute), as Ultimate Cron now handles the scheduling per job. If it is not possible to configure the crontab for every minute, I would suggest using poorman (or just use both to be sure, they do not interfere with each other).

2.) Set up cron. If no crontab on the server is set up, Drupal needs a user to visit a page for cron to run. More info on the concept of Poorman's cron can be found here

3.) Yes :-), "it's should" => "it shouldn't".

Yup. That's the goal of Ultimate Cron. Configure everything from within Drupal.

Yes, I think this would be ok. Also in the dev version of Ultimate Cron there's an extension to the cron syntax, and the default rule is "*/10+@ * * * *" where @ is a system generated offset, meaning that all jobs will run every ten minutes but not at the same minute. If you want to just run all jobs each hour, you can use the rule "@ * * * *".

I've installed both elysia_cron and ultimate_cron for comparison.

case 1)
elysia_cron - enabled
ultimate_cron - disabled

using external exec of cron.php,

	wget -U firefox --ca-certificate="/srv/sec/my_CA/my_CA.crt" --no-check-certificate -O - -t 1 https://test.loc/cron.php?cron_key=kPB...abc
--2012-07-08 10:35:03--  https://test.loc/cron.php?cron_key=kPB...abc
Resolving test.loc (test.loc)... 2001:xxx:xxxx:xxx::33, 192.168.1.33
Connecting to test.loc (test.loc)|2001:xxx:xxxx:xxx::33|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 0 [text/html]
Saving to: `STDOUT'

    [ <=>                                                                        ] 0           --.-K/s   in 0s

2012-07-08 10:35:03 (0.00 B/s) - written to stdout [0/0]

works as expected.

case 2)
same server,

elysia_cron - disabled
ultimate_cron - enabled

using external exec of cron.php,

	wget -U firefox --ca-certificate="/srv/sec/my_CA/my_CA.crt" --no-check-certificate -O - -t 1 https://test.loc/cron.php
		--2012-07-08 11:15:45--  https://test.loc/cron.php
		Resolving test.loc (test.loc)... 2001:xxx:xxxx:xxx::33, 192.168.1.33
		Connecting to test.loc (test.loc)|2001:xxx:xxxx:xxx::33|:443... connected.
		HTTP request sent, awaiting response... 403 Forbidden
		2012-07-08 11:15:45 ERROR 403: Forbidden.

What's different about ultimate_cron's access requirements?

You seem to be missing the cron key in the Ultimate Cron use case. Ultimate Cron does not implement any access checks that could produce a 403 when accessing cron.php. However, if accessing cron.php without a cron key (or an incorrect cron key) or if your site is in maintenance mode, you will get a 403.

Thanks, my mistake.

With elysia_cron, I see the cron_key field in the module Settings page.

With ultimate_cron, I do not - & mistakenly assumed it's not supported. So didn't use it.
Noting that is IT referenced/defined @ admin/reports/status, I (re)add the cron_key to the wget string, and it works.

Although I have the same 'doesn't update the status page' issue as I'd reported here: https://drupal.org/node/1675970.
Which makes me suspect it's NOT (just?) an elysia_ or ultimate_ issue.

I don't know why Elysia Cron has the cron key on it's settings page. Perhaps in order to be able to change it? I could add that though. Sounds like a could-be-useful feature.

About the status for cron's last run. The status DOES update on my setup. Looking at Ultimate Cron's code, I can see no reason why it shouldn't get updated? I currently have no theories to why you are experiencing this :-(. However with Elysia Cron, I could imagine you would experience this from time to time, as the variable is updated directly in the database, and the cache isn't maintained. Ultimate Cron also updates the db directly in order to prevent too many invalidations to the variables cache, but the cache is effectively bypassed for that particular variable when it's read.

> Perhaps in order to be able to change it?

It's changeable

> could-be-useful feature.

Nice, not critical.

> About the status for cron's last run. The status DOES update on my setup. Looking at Ultimate Cron's code, I can see no reason why it shouldn't get updated?

Hm. Some more info ... drush works ...

for reference,

	drush pm-list | grep -i cron
	 Other                      Elysia Cron (elysia_cron)                        Module  Disabled       7.x-2.1
	 Other                      Ultimate Cron (ultimate_cron)                    Module  Enabled        7.x-1.5+46-dev


	drush cron-list
	   Module              Function                                   Rules           Start                Duration
	   apachesolr          apachesolr_cron                            */10+@ * * * *  2012-07-08 11:10:10  00:00:00
	   ctools              ctools_cron                                */10+@ * * * *  N/A                  N/A
	   field               field_cron                                 */10+@ * * * *  N/A                  N/A
	   node                node_cron                                  */10+@ * * * *  2012-07-08 11:10:10  00:00:00
	   oauth_common        oauth_common_cron                          */10+@ * * * *  2012-07-08 11:10:10  00:00:00
	   progress            progress_cron                              */10+@ * * * *  2012-07-08 11:10:09  00:00:00
	   redirect            redirect_cron                              */10+@ * * * *  2012-07-08 11:10:09  00:00:00
	   search              search_cron                                */10+@ * * * *  N/A                  N/A
	   session_expire      session_expire_cron                        */10+@ * * * *  N/A                  N/A
	   statistics          statistics_cron                            */10+@ * * * *  N/A                  N/A
	   system              system_cron                                */10+@ * * * *  N/A                  N/A
	   ultimate_cron       ultimate_cron_cleanup_log                  */10+@ * * * *  N/A                  N/A
	   ultimate_cron       ultimate_cron_queue_background_process     * * * * *       2012-07-08 11:10:09  00:00:00
	   ultimate_cron       ultimate_cron_queue_insight_autoanalyze    * * * * *       2012-07-08 11:10:09  00:00:00
	   ultimate_cron       ultimate_cron_queue_views_bulk_operations  * * * * *       2012-07-08 11:10:09  00:00:00
	   update              update_cron                                */10+@ * * * *  2012-07-08 11:10:09  00:00:04

@ admin/reports/status
Cron maintenance tasks Last run 1 hour 51 min ago

Then

	wget -U firefox --ca-certificate="/srv/sec/my_CA/my_CA.crt" --no-check-certificate -O - -t 1 https://test.loc/cron.php?cron_key=XXX
	--2012-07-08 13:02:49--  https://test.loc/cron.php?cron_key=XXX
	Resolving test.loc (test.loc)... 2001:xxx:xxxx:xxx::33, 192.168.1.33
	Connecting to test.loc (test.loc)|2001:xxx:xxxx:xxx::33|:443... connected.
	HTTP request sent, awaiting response... 200 OK
	Length: 0 [text/html]
	Saving to: `STDOUT'

	    [ <=>                                                                        ] 0           --.-K/s   in 0s

	2012-07-08 13:02:49 (0.00 B/s) - written to stdout [0/0]

still not updated @ admin/reports/status
Cron maintenance tasks Last run 1 hour 52 min ago

but with drush

	drush cron
		Cron run successful.

it's updated, @ admin/reports/status
Cron maintenance tasks Last run 30 sec ago

I'm not clear if that drush cron exec is 'going through' ultimate_cron's task management/parallelization ... ?

When using "drush cron", Ultimate Cron is not invoked but only Drupal's regular cron is used, which could explain why the timestamp is properly updated.

I'm still not sure why it doesn't work for you when using wget. When ultimate cron runs, it updates the timestamp directly in the database. To bypass the cache, it loads the value from the db during hook_init() and stores it in the global $conf variable.

Could you check the value of "cron_last" directly in the db, immediately after you've run cron through wget?

> Could you check the value of "cron_last" directly in the db, immediately after you've run cron through wget?

> mysql testDB -e "SELECT * from variable where name='cron_last'"
	+-----------+---------------+
	| name      | value         |
	+-----------+---------------+
	| cron_last | i:1341777820; |
	+-----------+---------------+

> wget ...
> mysql testDB -e "SELECT * from variable where name='cron_last'"
	+-----------+---------------+
	| name      | value         |
	+-----------+---------------+
	| cron_last | i:1341777820; |
	+-----------+---------------+

> drush cron
	Cron run successful.         [success]
> mysql testDB -e "SELECT * from variable where name='cron_last'"
	+-----------+---------------+
	| name      | value         |
	+-----------+---------------+
	| cron_last | i:1341780038; |
	+-----------+---------------+

Hmmm. Do you get any watchdog messages from ultimate_cron?

@ wget ...

tail -f /var/log/drupal.log /var/log/apache2/access.log

==> /var/log/drupal.log <==
==> /var/log/apache2/access.log <==
test.loc 2001:xxx:xxxx:xxx::33, 127.0.0.1, 127.0.0.1, 2001:xxx:xxxx:xxx::33, 127.0.0.1, 127.0.0.1 - - [08/Jul/2012:14:34:31 -0700] "POST /bgp%3Astart/uc%253Aultimate_cron_queue_insight_autoanalyze/325bdd59ff8090b58d0965e1b15d0782 HTTP/1.0" 200 - "" "firefox"
test.loc 2001:xxx:xxxx:xxx::33, 127.0.0.1, 127.0.0.1, 2001:xxx:xxxx:xxx::33, 127.0.0.1, 127.0.0.1 - - [08/Jul/2012:14:34:31 -0700] "POST /bgp%3Astart/uc%253Aultimate_cron_queue_views_bulk_operations/ff9d4b779a81978dac255271903d31b7 HTTP/1.0" 200 - "" "firefox"
test.loc 2001:xxx:xxxx:xxx::33, 127.0.0.1, 127.0.0.1, 2001:xxx:xxxx:xxx::33, 127.0.0.1, 127.0.0.1 - - [08/Jul/2012:14:34:31 -0700] "POST /bgp%3Astart/uc%253Aultimate_cron_queue_background_process/4eecd66df0fcf9d56463fcbbe7a842fb HTTP/1.0" 200 - "" "firefox"
test.loc 2001:xxx:xxxx:xxx::33, 127.0.0.1, 127.0.0.1, 2001:xxx:xxxx:xxx::33, 127.0.0.1, 127.0.0.1 - - [08/Jul/2012:14:34:31 -0700] "POST /bgp%3Astart/uc%253Abackground_process_cron/9f24cfbebf3e5be0cc2c2e779d6fedfd HTTP/1.0" 200 - "" "firefox"

test.loc 2001:xxx:xxxx:xxx::33, 127.0.0.1, 127.0.0.1, 2001:xxx:xxxx:xxx::33, 127.0.0.1, 127.0.0.1 - - [08/Jul/2012:14:34:31 -0700] "POST /bgp%3Astart/uc%253Asystem_cron/7155cf00791ff6cad9b74b30c3f713ba HTTP/1.0" 200 - "" "firefox"
test.loc 2001:xxx:xxxx:xxx::33, 127.0.0.1, 127.0.0.1 - - [08/Jul/2012:14:34:30 -0700] "GET /cron.php?cron_key=XXX HTTP/1.0" 200 - "-" "firefox"

What about drupal's watchdog system (admin/reports/dblog)

> What about drupal's watchdog system (admin/reports/dblog)

Enabling the dblog module helps.

> wget ...

@ admin/reports/dblog

		cron    	07/08/2012 - 16:06    Number of sessions deleted: 0    Anonymous (not verified)

clicking on the message link,

Type        cron
Date        Sunday, July 8, 2012 - 16:06
User        Anonymous (not verified)
Location    https://test.loc/bgp%3Astart/uc%253Asession_expire_cron/1d1574b5c08aaa0e62198e66b4a5f3e0
Referrer
Message    Number of sessions deleted: 0
Severity   notice
Hostname   2001:xxx:xxxx:xxx::33
Operations

Ah. Could you try enabling the "Database logging" module? Then try out the cron, and revisit the admin/reports/dblog page afterwards.

> Could you try enabling the "Database logging" module?

It already *is* enabled:

Enabling the dblog module helps

drush pm-list | grep -i database
 Core                       Database logging (dblog)                         Module  Enabled        7.14 

The result, above, at comment #25, is with the module enabled.

Sorry, didn't see your last message.

Could you try "drush cron-run all" and see if this updates the timestamp?

np.

yes, it does,

> mysql testDB -e "SELECT * from variable where name='cron_last'"
	+-----------+---------------+
	| name      | value         |
	+-----------+---------------+
	| cron_last | i:1341789037; |
	+-----------+---------------+

> drush cron-run all
	12 jobs scheduled for launch
	12 jobs launched

> mysql testDB -e "SELECT * from variable where name='cron_last'"
	+-----------+---------------+
	| name      | value         |
	+-----------+---------------+
	| cron_last | i:1341837498; |
	+-----------+---------------+

and at the status page

Cron maintenance tasks Last run 5 sec ago

Hmm... Perhaps an odd question: If you disable both Elysia Cron and Ultimate Cron, then does the timestamp update if you do a wget?

failed to identify the source of the problem, but cured it.

disabling & uninstalling, then re-dl'ing+reenabling ultimate_cron made no difference.

clearing caches did nothing.

but disabling & uninstalling, then phsyically rm'ing the module directory, clearing all caches, and re-installing a completely clean/new instance of ultimate_cron seems to have fixed the problem. No other changes made.

@ wget ..., the StatusReport page now shows:

Cron maintenance tasks Last run 2 sec ago

refreshed once per minute.

To try to track down the problem, I reverted to a git revision of my module tree prior to this step -- and the problem is also/still gone. I can't get it to return/repeat.

Frustrating as this makes no sense to me, and there's no sign of what the problem was. I'll keep an eye out for any return of the problem.

It makes no sense to me either :-). Glad you got it to work though.

If the problem returns, please open another ticket so we won't spam previous followers of this ticket.

Hi,

Please could you put the list of main differences (not only Ultimate Cron features) in the module front page? It would help users to choose the right module, especially if -as you say- the two modules have different goals.

I plan to study the two modules in detail so I would like to help on this

Hi

I'm not really sure if this information is best suited on the project page. It depends on how verbose it will be. Also, I'm not sure of the differences in detail between Elysia Cron and Ultimate Cron anymore. We did try to initiate a join-forces project once, but that didn't go anywhere.

"Different goals" may have been a stretch. Both modules enhance the cron functionality in Drupal, but in their own ways, which are not always compatible (hook_cronapi definition for example). As a result they may provide different features that may appeal to different users. What i can say, is that one of the goals of Ultimate Cron is to control everything from within Drupal, without having the need to setup server crontabs etc., yet still providing this feature.

If you get an overview of the differences between the two modules, I would be happy to add it to the project page and/or documentation.

Cool thanks, I'll look into it