Cron: Difference between revisions

From MoodleDocs
(Upgrade page, split into many pages that are linked with template)
 
(43 intermediate revisions by 15 users not shown)
Line 1: Line 1:
{{Installing Moodle}}
{{Installing Moodle}}
Cron is the name of a Unix program that runs predefined tasks on a computer at regular intervals. The cron process in Moodle assists some modules to perform tasks on a scheduled basis. For example, the cron process might tell Moodle to check all discussion forums so it can mail out copies of new posts to people who have subscribed to that forum.  
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.


The Moodle cron process can not tell itself to run. It is a best practice to set up a cron service either on the hosting web server, another server or on another computer that will tell the Moodle cron process to run.  
'''IMPORTANT: Do not skip setting up the cron process on your server for your Moodle. Your site will not work properly without it.'''
 
It is recommended that ''the cron is run every minute'', as required for asynchronous activity deletion when using the [[Recycle bin|recycle bin]].
 
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. Most shared hosting systems use CPanel to manage sites, and usually will have a section for Cron Jobs on the panel.
 
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 <pre>/path/to/moodle/admin/cli/cron.php</pre> 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 <pre>/usr/bin/php /path/to/moodle/admin/cli/cron.php</pre> You can (and should) try this on your command line to see if it works. '''WARNING: Check your command-line PHP version is compatible with your chosen version of Moodle. The command-line PHP program is different to the one running your web site and is not always the same version.'''
# If, for some reason, you cannot run the CLI script there is the web based script. Note that this is now deprecated and may be removed in future versions. 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 <pre>/usr/bin/wget http://your.moodle.site/admin/cron.php</pre> 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.
 
===The web based Moodle cron command===
* If you have a choice, do not use the web based cron. It is likely to be removed in a future Moodle version.
* From Moodle 2.9 onwards, the cron job can no longer be run from web by default. You will get an error message:
!!! Sorry, internet access to this page has been disabled by the administrator. !!!
* You can change this in ' Site administration ► Security ► Site security settings ' by deselecting 'Cron execution via command line only'.
** You will be warned that 'Running the cron from a web browser can expose privileged information to anonymous users. Thus it is recommended to only run the cron from the command line or set a cron password for remote access.'
** You can then write a 'Cron password for remote access'. If this field is left empty, no password is required.
** This means that the cron.php script cannot be run from a web browser without supplying the password using the following form of URL:
  http://site.example.com/admin/cron.php?password=opensesame
 
=== 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''
<pre>
$ crontab -u www-data -e
</pre>
''This will open an editor window. To run the cli cron script every 1 minute, add the line:''
<pre>
*/1 * * * * /usr/bin/php  /path/to/moodle/admin/cli/cron.php >/dev/null
</pre>
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 ==
   
   
*[[Cron reports]] - Examples of reports shown after admin/cron.php was triggered
Choose the information for your server type:
*[[Cron settings]] - Moodle cron process password and CLI settings
 
*[[Cron with Unix or Linux]]- Cron services on various UNIX and Linux flavored operating systems.
*[[Cron with Windows OS]] - Cron services in Windows
*[[Cron with Windows OS]] - Cron services in Windows
*[[Cron with MAC OS X]]- Cron services in a MAC environment
*''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.
*[[Cron with web hosting services]]- Cron services in various web hosting examples.
*[[Cron with UNIX]]- Cron services on various UNIX and Linux flavored operating systems.


:Note: Asking a human to use their browser to run the Moodle cron process every five or ten minutes,or when anybody on the site thinks it needs to be run is not a best practice.  The outside cron service provides a "heartbeat" so that the Moodle cron process can perform functions at periods defined for each module that needs it.
Here are some more instructions for specific hosts (please check that these are up to date):


==Starting cron==
*[[Cron on 1and1 shared servers]]
There are a number of way to invoke Moodle cron process. Cron can be started from the address bar in a browser (For example http:demo.moodle.net/admin/cron.php), via a [[Daemon]], or wq1et, curl or some other form of a cron service.


===Cron service location and timing===
== Using third party cron service ==
Note that the machine providing the cron service  '''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 might choose to run cron on another server or on your home computer. All that matters is that the Moodle cron process is run on a regular basis.
Besides using cron hosted on your own server, you may use third party cron service (usually called webcron):


The load of the Moodle cron process on the Moodle server is not very high, so 5 minutes is usually reasonable. However if you're worried about it you can reduce the time period to something like 15 minutes or even 30 minutes.  
*[https://cron-job.org/ cron-job.org] is a free service. (1Minute cron is possible)
:It's best not to make the time period too long.  For example delaying mail-outs can slow down activity within the course and create a large mail outbox to process. Or student want to see their activity and course completions updated quickly. 


===Testing cron and manual trigger===
*[https://www.easycron.com EasyCron] - A webcron service provider that eliminates the need of crontab or other task schedulers to set cron job.
On a new Moodle install or upgrade, it is a good idea to test the Moodle cron process directly from your browser: ''<nowiki>http://example.com/moodle/admin/cron.php</nowiki>''  (See [[Cron settings]] if this does not work).


Next, you need to set up a way to manage an automatic scheduled process to run the script on a regular basis. This will depend upon the operating system and program you select.
=== Cron settings in Moodle ===


:Note: When the Moodle cron process is called from cron service, 'the command line' trigger creates a temporary admin environment (similar to a login) in order to run and then deletes that environment. You can disable command line running of cron by disabling the appropriate section in the cron.php file.
An admin can set cron execution via command line only or a cron password for remote access in 'Site security settings' in the Site administration.


==Moodle cron process ==
===Remote cron===
The Moodle cron process basically finds and determines if certain functions need to run. These functions are defined in code associated with specific activities and processes. Usually the function looks for new activity that has occurred since cron was last run.  Some of the functions may use a timestamp to determine if they should look for new activity. A few functions are run on a random basis.
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.


===Examples of Moodle cron processes===
==Scheduling tasks==
Moodle's cron processes include:
An administrator can schedule cron tasks very precisely from Administration > Site administration > Server > Scheduled tasks, see [[Scheduled tasks]]
*updating reports such as quiz, admin, gradebook
*updating course and activity completion (if enabled in advanced settings)
*updating portfolio
*plagiarism checks
*updates activity modules. It looks through the mod directory for lib.php files that contain the function activity-name_cron and will call it. In a standard install this includes assignment, chat, forum, and SCROM.
*updates blocks.  It looks for blocks for their cron methods (object functions) to be run.  It then, for each such block, runs the cron method for a new object associated with that block (for more details read admin/cron.php). These files (the lib.php files and the files where the block classes are defined) can contain cleanup functions, email functions or anything that needs to be run on a regular basis.
*create the backups of courses at the time specified in the administration settings.
*updating messaging module or forum email notifications.
*unenrol students - this is done on a random basis about 20% of the time Moodle's cron process is triggered.
*deleting users who have not filled out their profile via the 20% random trigger
*deleting old logs are also checked 20% of the time via the 20% random trigger
*deletes old cached text
*generates new passwords for new users and notifies users
*runs authentication enrolments processes
*updates stats if enabled.
*runs blog cleanups
*updates registrations


The code in lib/cronlib.php shows the places that are being checked when the admin/cron.php is run and the report which is displayed on the screen after it has run. As mentioned elsewhere admin/cli/cron.php is the file which outside cron services run to trigger the Moodle cron process.
==Running cron for several Moodle servers==
* Tasks can run in parallel and processes use locking to prevent tasks from running at the same time which allows cron to be triggered from multiple web servers that serve the same Moodle instance.
 
* If you are running different Moodle instances on the same server, 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 https://httpd.apache.org/docs/2.2/vhosts/index.html].)
 
== 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 add some automated checking of the output of running cron (e.g. searching 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 [[Administration via command line#Scheduled_tasks|cli scheduled task runner]] and monitor the output.


==See also==
==See also==
Using Moodle forum discussions:
 
*[http://moodle.org/mod/forum/discuss.php?d=41827 Cron - can someone give me a quick confirmation of function?]
* [[Scheduled tasks]]
*[http://moodle.org/mod/forum/discuss.php?d=97684 Cronjob Question]
* [http://en.wikipedia.org/wiki/Cron Wikipedia article on cron function]
*[http://moodle.org/mod/forum/discuss.php?d=97457 Slow cron : avoiding simultaneous cron]
* MDL-50694 - Cron message "The operation timed out while waiting for a lock" isn't really an error
*[http://moodle.org/mod/forum/discuss.php?d=117168 Visibility of cron.php]
 
Forum discussions:
*[http://moodle.org/mod/forum/discuss.php?d=139263#p609060 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.
*[http://moodle.org/mod/forum/discuss.php?d=139263#p609060 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.


[[de:Cron-Job]]
[[es:Cron]]
[[es:Cron]]
[[fr:Cron]]
[[fr:Cron]]
[[nl:Cron]]
[[it:Cron]]
[[sk:Cron]]
[[pl:Cron]]
[[ja:Cron]]
[[ja:Cron]]

Latest revision as of 07:40, 8 December 2018

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.

It is recommended that the cron is run every minute, as required for asynchronous activity deletion when using the recycle bin.

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. Most shared hosting systems use CPanel to manage sites, and usually will have a section for Cron Jobs on the panel.

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:

  1. identifying the correct command to run
  2. 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...

  1. 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. WARNING: Check your command-line PHP version is compatible with your chosen version of Moodle. The command-line PHP program is different to the one running your web site and is not always the same version.
  2. If, for some reason, you cannot run the CLI script there is the web based script. Note that this is now deprecated and may be removed in future versions. 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.

The web based Moodle cron command

  • If you have a choice, do not use the web based cron. It is likely to be removed in a future Moodle version.
  • From Moodle 2.9 onwards, the cron job can no longer be run from web by default. You will get an error message:
!!! Sorry, internet access to this page has been disabled by the administrator. !!! 
  • You can change this in ' Site administration ► Security ► Site security settings ' by deselecting 'Cron execution via command line only'.
    • You will be warned that 'Running the cron from a web browser can expose privileged information to anonymous users. Thus it is recommended to only run the cron from the command line or set a cron password for remote access.'
    • You can then write a 'Cron password for remote access'. If this field is left empty, no password is required.
    • This means that the cron.php script cannot be run from a web browser without supplying the password using the following form of URL:
 http://site.example.com/admin/cron.php?password=opensesame

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:

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

An admin can set cron execution via command line only or a cron password for remote access in 'Site security settings' in the Site administration.

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.

Scheduling tasks

An administrator can schedule cron tasks very precisely from Administration > Site administration > Server > Scheduled tasks, see Scheduled tasks

Running cron for several Moodle servers

  • Tasks can run in parallel and processes use locking to prevent tasks from running at the same time which allows cron to be triggered from multiple web servers that serve the same Moodle instance.
  • If you are running different Moodle instances on the same server, 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.)

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 add some automated checking of the output of running cron (e.g. searching 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

Forum discussions: