Note: You are currently viewing documentation for Moodle 3.2. Up-to-date documentation for the latest stable version of Moodle is probably available here: Cron.

Cron: Difference between revisions

From MoodleDocs
m ("unenrolling" instead of "enrolling")
m ("queued" instead of "qued")
Line 7: Line 7:
Note that the machine performing the cron '''does not need to be the same machine that is running Moodle'''. For example, if you have a limited web hosting service that does not have a cron service, then you can might choose to run cron on another server or on your home computer. All that matters is that the cron.php file is called regularly.
Note that the machine performing the cron '''does not need to be the same machine that is running Moodle'''. For example, if you have a limited web hosting service that does not have a cron service, then you can might choose to run cron on another server or on your home computer. All that matters is that the cron.php file is called regularly.


The load of this script is not very high, so 5 minutes is usually reasonable, but if you're worried about it you can reduce the time period to something like 15 minutes or even 30 minutes. It's best not to make the time period too long, as delaying mail-outs can slow down activity within the course. Remember that mail-outs also wait for the editing time to expire before being qued for sending.
The load of this script is not very high, so 5 minutes is usually reasonable, but if you're worried about it you can reduce the time period to something like 15 minutes or even 30 minutes. It's best not to make the time period too long, as delaying mail-outs can slow down activity within the course. Remember that mail-outs also wait for the editing time to expire before being queued for sending.


First, test that the script works by running it directly from your browser: ''<nowiki>http://example.com/moodle/admin/cron.php</nowiki>''
First, test that the script works by running it directly from your browser: ''<nowiki>http://example.com/moodle/admin/cron.php</nowiki>''
Line 33: Line 33:
Note in this example that the output is thrown away (to /dev/null).
Note in this example that the output is thrown away (to /dev/null).


A number of users of Moodle have found that'wget' sometimes fails. Especially if you have trouble with email digests not being sent on a daily basis to all users, an alternative command that solves the problem is:
A number of users of Moodle have found that 'wget' sometimes fails. Especially if you have trouble with email digests not being sent on a daily basis to all users, an alternative command that solves the problem is:


  php <nowiki>http://example.com/moodle/admin/cron.php</nowiki>
  php <nowiki>http://example.com/moodle/admin/cron.php</nowiki>


Note in this example that the output is thrown away (to /dev/null).
The same thing using lynx:
The same thing using lynx:


  lynx -dump <nowiki>http://example.com/moodle/admin/cron.php</nowiki> > /dev/null
  lynx -dump <nowiki>http://example.com/moodle/admin/cron.php</nowiki> > /dev/null
Note in this example that the output is thrown away (to /dev/null).


Alternatively you could use a standalone version of PHP, compiled to be run on the command line. The advantage with doing this is that your web server logs aren't filled with constant requests to cron.php. The disadvantage is that you need to have access to a command-line version of php.
Alternatively you could use a standalone version of PHP, compiled to be run on the command line. The advantage with doing this is that your web server logs aren't filled with constant requests to cron.php. The disadvantage is that you need to have access to a command-line version of php.

Revision as of 13:06, 6 April 2006

Some of Moodle's modules require continual checks to perform tasks. For example, Moodle needs to check the discussion forums so it can mail out copies of posts to people who have subscribed.

The script that does all this is located in the admin directory, and is called cron.php. However, it can not run itself, so you need to set up a mechanism where this script is run regularly (eg every five or ten minutes). This provides a "heartbeat" so that the script can perform functions at periods defined by each module. This kind of regular mechanism is known as a cron service.

The cron.php script looks through all the module directories for cron.php files and runs them. These files can contain cleanup functions, email functions or anything that needs to be run on a regular basis. For example, cron will trigger the system to create the backups of courses at the time specified in the administration settings. It also triggers any messaging module or forum email notifications, but not all functions are called each time the cron runs. Some functions, such as unenrolling students who have not logged in or deleting old copies of log files, are only run occasionally. The cron.php file has a section which will randomly call these core tasks approximately 1 in 5 times the cron runs.

Note that the machine performing the cron does not need to be the same machine that is running Moodle. For example, if you have a limited web hosting service that does not have a cron service, then you can might choose to run cron on another server or on your home computer. All that matters is that the cron.php file is called regularly.

The load of this script is not very high, so 5 minutes is usually reasonable, but if you're worried about it you can reduce the time period to something like 15 minutes or even 30 minutes. It's best not to make the time period too long, as delaying mail-outs can slow down activity within the course. Remember that mail-outs also wait for the editing time to expire before being queued for sending.

First, test that the script works by running it directly from your browser: http://example.com/moodle/admin/cron.php

If cron is called from the command line by any user logged in to your Moodle it will create a temporary admin environment in order to run and then log the user out. You can disable command line running of cron by disabling the appropriate section in the cron.php file.

Now, you need to set up some of way of running the script automatically and regularly.

On Windows systems

The simplest way is to use this little package moodle-cron-for-windows.zip which makes this whole thing very easy by installing a small Windows service. Run it and forget about it! :-)

On web hosting services

Your web-based control panel may have a web page that allows you to set up this cron process. For example, on Cpanel system, look for a button called "Cron jobs". In there you can put the same sort of Unix commands as listed below.

Using the command line on Unix

There are different command line programs you can use to call the page from the command line. Not all of them may be available on a given server.

For example, you can use a Unix utility like 'wget':

wget -q -O /dev/null http://example.com/moodle/admin/cron.php

Note in this example that the output is thrown away (to /dev/null).

A number of users of Moodle have found that 'wget' sometimes fails. Especially if you have trouble with email digests not being sent on a daily basis to all users, an alternative command that solves the problem is:

php http://example.com/moodle/admin/cron.php

The same thing using lynx:

lynx -dump http://example.com/moodle/admin/cron.php > /dev/null

Note in this example that the output is thrown away (to /dev/null).

Alternatively you could use a standalone version of PHP, compiled to be run on the command line. The advantage with doing this is that your web server logs aren't filled with constant requests to cron.php. The disadvantage is that you need to have access to a command-line version of php.

/opt/bin/php /web/moodle/admin/cron.php

Using the crontab program on Unix

All that Cpanel does is provide a web interface to a Unix utility known as crontab. If you have a command line, you can set up crontab yourself using the command:

crontab -e

and then adding one of the above commands like:

*/5 * * * * wget -q -O /dev/null http://example.com/moodle/admin/cron.php

Usually, the "crontab" command will put you into the 'vi' editor. You enter "insert mode" by pressing "i", then type in the line as above, then exit insert mode by pressing ESC. You save and exit by typing ":wq", or quit without saving using ":q!" (without the quotes).

See also