Cron: Difference between revisions
Damyon Wiese (talk | contribs) |
Damyon Wiese (talk | contribs) |
||
Line 95: | Line 95: | ||
Sometimes, a particular cron task may not be working correctly. In Moodle versions before 2.7 - any cron task that was throwing exceptions would prevent the rest of cron from running. The only way to monitor if cron was completing each time, was to check the output of running cron and to search for the string "Cron completed at ". | Sometimes, a particular cron task may not be working correctly. In Moodle versions before 2.7 - any cron task that was throwing exceptions would prevent the rest of cron from running. The only way to monitor if cron was completing each time, was to check the output of running cron and to search for the string "Cron completed at ". | ||
In Moodle 2.7 and later, a single failing scheduled task will not prevent the remaining tasks from completing. When any single scheduled task fails, it is marked as a failure, and scheduled to be reattempted. If the task keeps failing, the next scheduled time will be backed off until it is attempted at most once every 24 hours. But checking the scheduled tasks admin page, you can see if any task is currently failing (it will have a non-zero fail delay - which is the number of seconds to wait before reattempting a failed task). A simple way to debug a failing task, is to run it immediately using the [ | In Moodle 2.7 and later, a single failing scheduled task will not prevent the remaining tasks from completing. When any single scheduled task fails, it is marked as a failure, and scheduled to be reattempted. If the task keeps failing, the next scheduled time will be backed off until it is attempted at most once every 24 hours. But checking the [[scheduled tasks]] admin page, you can see if any task is currently failing (it will have a non-zero fail delay - which is the number of seconds to wait before reattempting a failed task). A simple way to debug a failing task, is to run it immediately using the [[Administration via command line#Scheduled_tasks|cli scheduled task runner]] and monitor the output. | ||
==See also== | ==See also== |
Revision as of 09:17, 9 May 2014
The Moodle 'cron' process is a PHP script (part of the standard Moodle installation) that must be run regularly in the background. The Moodle cron script runs different tasks at differently scheduled intervals.
IMPORTANT: Do not skip setting up the cron process on your server for your Moodle. Your site will not work properly without it
A special program (typically called - not surprisingly - 'cron') is used to run the Moodle cron script at a regular interval. The Moodle cron script runs tasks include sending mail, updating Moodle reports, RSS feeds, activity completions, posting forum messages and other tasks. Since different tasks have different schedules, not every task will run in Moodle when the cron script is triggered.
The cron program (that runs the Moodle script) is a core part of Unix based systems (including Linux and OSX) being used to run all manner of time-dependent services. On Windows the simplest solution is to create a task in the Windows Task Scheduler and set it to run at regular intervals. On shared hosting, you should find the documentation (or ask support) how cron is configured.
Essentially, the task involves adding a single command to the list of cron activities on your system. On Unix based systems this list is a file called a 'crontab' which all users have.
General discussion
See the later sections for your server type; this section contains some general background information.
There are essentially two steps to implementing cron:
- identifying the correct command to run
- finding the right place on your system to put the command
Working out the Moodle cron command
Moodle has two different ways to deploy cron which use different scripts within the Moodle install. These are as follows...
- The CLI (command line interpreter) script. This will be at the path
/path/to/moodle/admin/cli/cron.php
If in doubt, this is the correct script to use. This needs to be run by a 'PHP CLI' program on your computer. So the final command may look something like/usr/bin/php /path/to/moodle/admin/cli/cron.php
You can (and should) try this on your command line to see if it works. - The web based script. This needs to be run from a web browser and will be accessed via a web url something like http://your.moodle.site/admin/cron.php. You can find command line based web browser (e.g. wget) so the final command may look like
/usr/bin/wget http://your.moodle.site/admin/cron.php
This has the advantage that it can be run from *anywhere*. If you can't get cron to work on your machine it can be run somewhere else.
Finding the right place to put the command
This really does depend on the system you are using and you should find and read the documentation for your platform or hosting. In most cases getting the Moodle cron to run consists of establishing the correct command (above) and then adding it, and the time to run the command, to some sort of file. This might be either through a specific user interface or by editing the file directly.
If using the CLI version you also need to make sure that the cron process is run as the correct user. This is not an issue with the web version.
Example... installing cron on Ubuntu/Debian Linux. Assuming logged in as root..
use the crontab command to open a crontab editor window for the www-data user. This is the user that Apache (the web server) runs as on Debian based systems
$ crontab -u www-data -e
This will open an editor window. To run the cli cron script every 1 minute, add the line:
*/1 * * * * /usr/bin/php /path/to/moodle/admin/cli/cron.php >/dev/null
NOTE: the final >/dev/null sends all the output to the 'bin' and stops you getting an email every 1 minute.
Setting up cron on your system
Choose the information for your server type:
- Cron with Unix or Linux- Cron services on various UNIX and Linux flavored operating systems.
- Cron with Windows OS - Cron services in Windows
- Apple OSX - use the built-in 'crontab' service which is exactly the same as Cron with Unix or Linux. However, you might want to do it the 'Apple way' using launchd - see Cron with MAC OS X
- Cron with web hosting services- Cron services in various web hosting examples.
Here are some more instructions for specific hosts (please check that these are up to date):
Using third party cron service
Besides using cron hosted on your own server, you may use third party cron service (usually called webcron):
- EasyCron - A webcron service provider that eliminates the need of crontab or other task schedulers to set cron job.
Cron settings in Moodle
There are settings within Moodle that control aspects of cron operation:
- Cron settings - Moodle cron process password and CLI settings
Remote cron
Using the 'web based' version of cron it is perfectly ok to place the cron process on a different machine to the Moodle server. For example, the cron service on a Unix server can invoke the cron web 'page' on a Windows based Moodle server.
Running cron for several Moodle servers
- If both your servers are web servers, and they jointly serve one Moodle instance (in some sort of a cluster), then only one server should run the Moodle cron job.
- If those two web servers run different Moodle instances, then each Moodle instance needs a cron job. (Even a single Apache web server can run different Moodle instances on different domains by using its virtual hosts capability https://httpd.apache.org/docs/2.2/vhosts/index.html.)
- If you mean this setup, https://moodle.org/mod/forum/discuss.php?d=238005, then it is _one_ web server and _one_ Moodle instance. Then one cron job is the right answer.
- See this forum thread.
Cron in Moodle 2.7+
Cron has received a major update and now has support for both scheduled and adhoc tasks - MDL-25499. The benefits of these changes are:
- The schedule for every task can be configured by the admin. See Scheduled tasks
- Tasks can run in parallel
- Cron processes use locking to prevent the same task running at the same time by different processes
A result of this is that cron can be run much more often, which means (for example) forum posts can be sent out sooner. Admins can keep cron running at the same schedule as before, but it is strongly recommended that they increase the frequency of running cron to at least once per minute.
Debugging Scheduled Tasks
Sometimes, a particular cron task may not be working correctly. In Moodle versions before 2.7 - any cron task that was throwing exceptions would prevent the rest of cron from running. The only way to monitor if cron was completing each time, was to check the output of running cron and to search for the string "Cron completed at ".
In Moodle 2.7 and later, a single failing scheduled task will not prevent the remaining tasks from completing. When any single scheduled task fails, it is marked as a failure, and scheduled to be reattempted. If the task keeps failing, the next scheduled time will be backed off until it is attempted at most once every 24 hours. But checking the scheduled tasks admin page, you can see if any task is currently failing (it will have a non-zero fail delay - which is the number of seconds to wait before reattempting a failed task). A simple way to debug a failing task, is to run it immediately using the cli scheduled task runner and monitor the output.
See also
Using Moodle forum discussions:
- Cron - can someone give me a quick confirmation of function?
- Cronjob Question
- Slow cron : avoiding simultaneous cron
- Visibility of cron.php
- How to log the output of a Scheduled Task on Windows - this discussion explains a nice trick that can be very useful when you are experiencing problems with your Windows Scheduled Task and you need to log the output of the Scheduled Task to a log file.