Moodle настройка cron ubuntu
Обновлено: 07.07.2024
Правильно настроил cron для Moodle
После установки Moodle, в папке, вы найдете /admin/cron.php , который должен регулярно запускаться в фоновом режиме. Вы должны правильно настроить в процессе установки и настройки, но. если вы переносите Moodle на другой сервер или хостинг - об этой настройке можно забыть.
По сути, все дело состоит в том, чтобы добавить одну команду в список операций cron в вашей системе. В системах на основе Unix этот список представляет собой файл под названием «crontab», который есть у всех пользователей.
Очень много споров и обсуждений на тему правильной настройки cron для Moodle, но как по мне - все однозначно описано в документации, рассмотрены все возможные варианты для всех типов ОС. Сервер, наш, Ubuntu 16 лучше всего выполнить следующий порядок действий:
Оптимизация таблиц базы данных в PHPMyAdmin
Оптимизация таблиц или дефрагментация индексов таблиц необходима, так как в базе данных Moodle постоянно добавляются и удаляются данные (записи). Проще говоря оптимизация таблиц БД позволяет убрать «пустые» ключи, тем самым ускоряя в будущем операции выборки, а так же уменьшает общий размер базы данных.
Чтобы выполнить оптимизацию таблиц в phpMyAdmin необходимо:
Рекомендуется хотя бы раз в месяц проводить дефрагментацию таблиц на таких сайтах как электронные магазины, форумы, блоги.
В моем случае, общий размер таблиц базы данных уменьшился с 253,5Mb до 204,3Mb.
Ускоряем (оптимизируем) Apache
Включает кэш браузера. Установим модуль Apache mod_expires или mod_headers командами (оба модуля использовать ни к чему):
sudo a2enmod expires
или
sudo a2enmod headers
перезагрузим сервер Apache:
sudo service apache2 reload
Я использовал модуль expires и в файл .htaccess добавил:
<IfModule mod_expires.c>
ExpiresActive On
ExpiresDefault "access plus 1 day"
ExpiresByType application/javascript "access plus 1 week"
ExpiresByType image/x-icon "access plus 1 month"
ExpiresByType image/gif "access plus 1 month"
ExpiresByType image/png "access plus 1 month"
ExpiresByType image/jpg "access plus 1 month"
ExpiresByType image/jpeg "access plus 1 month"
ExpiresByType text/css "access plus 1 month"
</IfModule>
Если вы будите использовать headers в файл .htaccess нужно добавить:
Об этом можно прочесть здесь
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.
Contents
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 web based Moodle cron command
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
This will open an editor window. To run the cli cron script every 1 minute, add the line:
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 services on various UNIX and Linux flavored operating systems. - 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 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):
-
is a free service. (1Minute cron is possible)
-
- A webcron service provider that eliminates the need of crontab or other task schedulers to set cron job.
-
- A free and easy webcron service provider.
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
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.
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.
Contents
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 web based Moodle cron command
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
This will open an editor window. To run the cli cron script every 1 minute, add the line:
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 services on various UNIX and Linux flavored operating systems. - 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 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):
-
is a free service. (1Minute cron is possible)
-
- A webcron service provider that eliminates the need of crontab or other task schedulers to set cron job.
-
- A free and easy webcron service provider.
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
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.
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.
Contents
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 web based Moodle cron command
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
This will open an editor window. To run the cli cron script every 1 minute, add the line:
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 services on various UNIX and Linux flavored operating systems. - 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 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):
-
is a free service. (1Minute cron is possible)
-
- A webcron service provider that eliminates the need of crontab or other task schedulers to set cron job.
-
- A free and easy webcron service provider.
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
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.
Logging and monitoring
Ideally you should also be logging the output of cron somewhere and monitoring it for issues. You can monitor the overall status of cron to make sure there are no errors by visiting:
Site administration / Reports / System status (/report/status/index.php)
If there are errors then you can get more details for recently run tasks from the Logs column on the Scheduled task page, but this won't show ad hoc task failures:
Site administration / Server / Tasks / Scheduled tasks (/admin/tool/task/scheduledtasks.php)
To see ad hoc task failures you either need to rerun the task manually yourself and see the errors, or you need to have already collected the logs for review. For a Moodle running on a single box you could log to a simple log file, or for a cluster you might want to use syslogd or similar, e.g.:
Low latency adhoc tasks
Each time cron is run, after the scheduled tasks the ad hoc tasks are also run. While scheduled tasks can run at most once a minute, ad hoc tasks can be queued at any moment, and generally you want them processed as soon as possible and to not have to wait for the scheduled task to run first. If you only run the normal admin/cli/cron.php then not only might it have to wait to process all the scheduled tasks first, if it has already finished you will have to wait until the next minute for cron to start again for it to be processed.
Instead you can run one or more dedicated ad hoc task processors which run in parallel to the main cron process.
Starting from Moodle 3.9 the—keep-alive option runs like a daemon so when the queue is empty rather than exiting it waits for new tasks to be queued so it can start processing as soon as possible.
Scaling up cron with multiple processes
As your site grows many of the scheduled tasks will take longer to complete, and also there will be more ad hoc tasks queued which need to be processed. The cron system is designed to work in parallel but each individual process can only process one task at a time so you must run multiple cron cli's. You can generally run a fairly high number of cron processes on a dedicated cron instance before needing to run multiple cron instances. To run more than one process simply spawn multiple cron processes each minute:
It can be especially important to increase the number of adhoc_task.php processes as certain plugins and systems can generate very large numbers of ad hoc tasks, or tasks that can take a long time to process. Especially tasks like document conversions and automated backups can build up more quickly than they are processed if they are left on default settings.
By default only 3 scheduled tasks and 3 ad hoc tasks can be run concurrently so as you add more processes you need to increase the level of allowed concurrency:
Site administration > Server > Tasks > Task processing
Or in config.php :
Whatever you set these too make sure the server(s) hosting them can comfortably handle this many processes. Often the bottleneck will be a shared service, usually the database.
You may find that certain types of very long running tasks will consume all the available task processes which means no other tasks will run. e.g. if you have 5 cli processes, but in the task queue there are 20 ad hoc tasks for an automated backup, each of which will take ten minutes to complete, then very quickly all 5 processes will be consumed by backups and nothing else. Other small very fast and light tasks like a document conversion or forum emails will not get sent until the backups are complete and a process frees up. To manage this you can limit the concurrency of specific types of ad hoc tasks. A good rule of thumb is that if all of the 'heavy' tasks consume all of their own limits then you should still have another few processes standing by on idle waiting for anything else which may be added to the queue.
Automated backups are the worst known offender, so hypothetically if you are running 50 ad hoc task processes concurrently a reasonable restriction might be to cap the backups to consume no more than half of those processes, ie 25 at most:
Читайте также: