make cron.php compatible to php-cli (or change documentation) [#1192102]

The drupal installation guide currently tells you that alternatively to setting up your crontab call using curl, you could also do the following:
"/usr/bin/php /home/sites/example.com/public_html/cron.php"

However, in D7 this will fail for several reasons:

1) cron.php uses getcwd() to determine its own path. Since php-cli does not change the current work path when executing a script, it getcwd will return something like "/root".

2) You are now required to pass a curl_key via $_GET, which is impossible through the command line. You could alternatively pass it through a second command line parameter as $argv[1]:
"php /home/sites/example.com/public_html/cron.php xxxxxxxxx_xxxxxxxxxxxxxxxxxxxxxx"

3) $_SERVER['REMOTE_ADDR'] will not be defined in a cli call. This leads at least to a number of annoying E_NOTICES from php when bootstrap.inc tries to access it.

I'm attaching a modified version of cron.php that deals with all these problems.

It might not always be the best option to use cli (for instance because opcode caching does not work), but I still think it should remain an option. We will for instance handle some cpu intensive tasks through it that might make the script time out if called through the web interface.

Comment	File	Size	Author
#4	cron.php_.txt	1.4 KB	ralf.strobel
#1	cron.php_.txt	926 bytes	ralf.strobel
	cron.php_.txt	950 bytes	ralf.strobel

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

ralf.strobel CreditAttribution: ralf.strobel commented 17 June 2011 at 19:04

File	Size
cron.php_.txt	926 bytes

On second thought it might be better to bypass the check for cron_key all together for calls from localhost.
New version attached...

Comment #2

ralf.strobel CreditAttribution: ralf.strobel commented 17 June 2011 at 21:19

Some more notices that can come up concern unavailability of $_SERVER['REQUEST_METHOD'] and $_SERVER['SERVER_SOFTWARE'].

Comment #3

Phizes CreditAttribution: Phizes commented 22 June 2011 at 13:35

As a side note you can run cron.php from the command line with drupal.sh

/path/to/drupal_root/scripts/drupal.sh --root "/path/to/drupal_root/" http://example/cron.php?cron_key=your_key

Though this does not work if drupal is installed in a subdirectory like http://example/drupal/cron.php as it assumes the path you want to access is drupal/cron.php and the file it executes then is index.php, this is even despite setting the base path in settings.php. It does take care of the environment variables though.

Perhaps that would be worth adding to the docs in the meantime?

Comment #4

ralf.strobel CreditAttribution: ralf.strobel commented 12 September 2011 at 20:05

File	Size
cron.php_.txt	1.4 KB

I'm attaching a more sophisticated version of my initial replacement.
Since there is currently no development on this, it's the solution I will keep using for larger web sites.
We're running some relatively complex tasks through cron that may cause http requests to time out.

There should be no error messages or any other side effects any more.

Only thing to keep in mind is that you should refrain from using APC to cache variables, since they will not be available through php-cli and require a full cache rebuild on every execution. I'm using memcached instead, connected through a unix socked and serialized using igbinary. That is giving similar if not superior performance to APC.

Comment #5

idflood CreditAttribution: idflood commented 11 October 2011 at 06:20

I will certainly hit this issue in a near future (subscribing)

Comment #6

patacra CreditAttribution: patacra commented 30 March 2012 at 07:12

I agree with Phizev that this is a better way to call the cron. I am currently using it for a few sites.

But I have noticed that drupal.sh does not set the variable $_SERVER['SCRIPT_NAME'] (which should be the same as $_SERVER['PHP_SELF']). The problem is that Drupal's bootstrap will init some global variables (such as $base_path and $base_url) according to $_SERVER['SCRIPT_NAME']. This results in creating wrong URLs when your cron uses url(), l() or similar functions.

I'll try to prepare a patch and submit it in order to fix this problem.

Comment #7

Phizes CreditAttribution: Phizes commented 30 March 2012 at 11:50

I'm currently using a script I wrote/cobbled together a while ago in this blog post. Nothing special really.

I have used it now for several months on a couple of basic sites, and it seems to do it's job just fine but it's not tested on complex setups, and it probably doesn't fix the problem of incorrect URL's. I haven't had the need to look at it in ages.