Totara has a time-based job scheduler called Cron, which has received a major update and now has support for both scheduled and adhoc tasks . The benefits of these changes are:
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.
The Totara 'cron' process is a PHP script (part of the standard Totara installation) that must be run regularly in the background. The Totara cron script runs different tasks at differently scheduled intervals.
|Do not skip setting up the cron process on your server for your Totara. Your site will not work properly without it.|
The Totara cron script runs tasks include sending mail, updating Totara reports, RSS feeds, activity completions, posting forum messages, and other tasks. Since different tasks have different schedules, not every task will be run every time the cron script is triggered.
The cron program (which runs the Totara script) is a core part of Unix based systems (including Linux and OSX) being used to run many 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.
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.
Totara has two different ways to deploy cron which use different scripts within the Totara install. These are as follows:
This will be at the path /path/to/Totara/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/Totara/admin/cli/cron.php. You can (and should) try this on your command line to see if it works.
This needs to be run from a web browser and will be accessed via a web URL something like '. You can find command line based web browser (e.g. wget) so the final command may look like '/usr/bin/wget . 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.
An important feature is the cron scheduler UI for administrators (available here:Site administration > Server > Scheduled tasks). Use the scheduler feature to display a list of tasks executed by cron. This includes displaying when the task last ran, and when it is expected to next be run.
Site administrators can take control of the background processes running for their Totara site. This feature brings visibility to the Totara cron making it easier to see what's going on, debug slow or failing processes, and to take control of and optimise cron.
Each task can also be configured to run at the desired time on any desired day.
System Administrators with command line access can now also manually run a single task if required by executing 'admin/tool/task/cli/schedule_task.php' with the required arguments.
Scheduled cron tasks:
--execute=\\some\\task Execute scheduled task manually
--list List all scheduled tasks
-h, --help Print out this help
$sudo -u www-data /usr/bin/php admin/tool/task/cli/scheduled_task.php --execute=\\core\\task\\session_cleanup_task
Those running their site in a hosted environment where changes to system cron cannot be made or must be put through a request and approval process also benefit from in-product configuration.
This depends on the system you are using and you should find and read the documentation for your platform or hosting. In most cases getting the Totara 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 15 minutes, add the line:
*/15 * * * * /usr/bin/php /path/to/Totara/admin/cli/cron.php >/dev/null
Note that the final ">/dev/null" sends all the output to the 'bin' and stops you getting an email every 15 minutes.
Generally speaking, those tasks that run daily are the ones that you are more likely to need to pay close attention to, particularly on larger sites. Performance impacts are going to be dependant on how much information needs to be processed each time this task runs and what timing you're changing the task to e.g. changing an hourly task to one that runs every 30 minutes could be fine, but reducing it to run each and every minute could have an impact.
Its advisable to monitor these task timings for any issues. The cron logs will give an understanding of the time it takes to execute a particular task and based on this adjustments can be made to improve site performance.
As all sites differ and cron performance is dependent on the usage of various features it is difficult to offer a general or 'ideal' configuration.