Cron

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 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.

• Cron reports - Examples of reports shown after admin/cron.php was triggered
• Cron settings - Moodle cron process password and CLI settings
• Cron with Windows OS - Cron services in Windows
• Cron with MAC OS X- Cron services in a MAC environment
• 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.

Starting cron

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

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.

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.

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

On a new Moodle install or upgrade, it is a good idea to test the Moodle cron process directly from your browser: http://example.com/moodle/admin/cron.php (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.

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.

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.

Moodle cron process

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.

Examples of Moodle cron processes

Moodle's cron processes include:

• 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.

See also

• All About the Moodle Cron Job

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.