« Cron » : différence entre les versions

De MoodleDocs
Aller à :navigation, rechercher
m (Nouveau formatage du code)
Ligne 132 : Ligne 132 :
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:
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:


<code>
<pre>
  * * * * * /usr/bin/php  /path/to/moodle/admin/cli/cron.php
  * * * * * /usr/bin/php  /path/to/moodle/admin/cli/cron.php
  * * * * * /usr/bin/php  /path/to/moodle/admin/cli/cron.php
  * * * * * /usr/bin/php  /path/to/moodle/admin/cli/cron.php
Ligne 141 : Ligne 141 :
  * * * * * /usr/bin/php  /path/to/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59
  * * * * * /usr/bin/php  /path/to/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59
...
...
</code>
</pre>


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.
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.
Ligne 149 : Ligne 149 :
Site administration > Server > Tasks > Task processing
Site administration > Server > Tasks > Task processing


<code php>
Ou dans <code>config.php</code> :
config.php:
 
<syntaxhighlight lang="php">
$CFG->task_scheduled_concurrency_limit = 20; // Defaults to 3
$CFG->task_scheduled_concurrency_limit = 20; // Defaults to 3
$CFG->task_adhoc_concurrency_limit = 50; // Defaults to 3
$CFG->task_adhoc_concurrency_limit = 50; // Defaults to 3
</code>
</syntaxhighlight>


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.
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.
Ligne 161 : Ligne 162 :
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:
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:


<code php>
Dans <code>config.php</code> :
config.php:
 
<syntaxhighlight lang="php">
$CFG->task_concurrency_limit = [
$CFG->task_concurrency_limit = [
     'core\task\course_backup_task' => 25,
     'core\task\course_backup_task' => 25,
     'core_course\task\course_delete_modules' => 5,
     'core_course\task\course_delete_modules' => 5,
];
];
</code>
</syntaxhighlight>


== Voir aussi ==
== Voir aussi ==

Version du 27 août 2021 à 09:41

Remarque : la traduction de cette page n'est pas terminée. N'hésitez pas à traduire tout ou partie de cette page ou à la compléter. Vous pouvez aussi utiliser la page de discussion pour vos recommandations et suggestions d'améliorations.

Le processus Moodle cron est un script PHP, partie intégrante de la distribution standard de Moodle, qui doit être lancé régulièrement. Ce script lance diverses tâches programmées à différents intervalles.

IMPORTANT ! Ne sautez pas l'étape de configuration du processus cron sur le serveur hébergeant votre installation de Moodle. Votre site ne fonctionnera pas correctement sans lui !

Il est recommandé de lancer le cron à une fréquence d'une fois par minute, comme cela est requis pour la suppression synchrone des activités lors de l'utilisation de la corbeille.

Le programme cron (qui lance le script cron de Moodle) fait partie de façon standard des systèmes Unix (y compris Linux et macOS) et est utilisé pour lancer toutes sortes de services dépendant de l'heure. Sous Windows, la solution la plus simple pour répliquer ce comportement est de créer une tâche dans le Gestionnaire des tâches Windows et de la faire lancer à intervalles réguliers. Sur les serveurs mutualisés, il vous faudra trouver la documentation (ou demander de l'assistance) sur la façon de configurer le cron. La plupart des serveurs mutualisés offrent CPanel pour gérer les sites, et auront donc une section pour configurer les tâches Cron sur le panneau de configuration.

Normalement, pour configurer le cron, il s'agit d'ajouter une unique commande à la liste des activités du cron déjà existantes sur votre système. Sur les systèmes Unix, cette liste est contenue dans le fichier dénommé crontab, propre à chaque utilisateur.

Discussion générale

Ce paragraphe détaille diverses informations de base. Voyez plus loin pour des instructions propres à votre type de serveur.

Deux étapes sont essentielles pour faire fonctionner le cron :

  1. identifier la commande correcte à lancer, et
  2. trouver le bon endroit où indiquer cette commande sur votre système.

Comprendre le script cron de Moodle

Moodle a deux façons différentes de déployer le cron, qui utilisent deux scripts différents de l'installation de Moodle.

  1. Le script CLI (command line interpreter = interface en ligne de commande). Ce script se trouve ici :
    /chemin/de/moodle/admin/cli/cron.php
    Si vous ne savez pas que faire, c'est ce script que vous devez utiliser. Il nécessite d'être lancé sur votre serveur par PHP en ligne de commande. La commande à lancer ressemblera donc à quelque chose comme
    /usr/bin/php /chemin/de/moodle/admin/cli/cron.php
    Vous pouvez (et devez) tester cette commande à la main pour voir si elle fonctionne. Attention ! Vérifiez que la version de PHP en ligne de commande est compatible avec votre version de Moodle. Le programme PHP en ligne de commande est différent de celui utilisé par le serveur web et n'est pas toujours à la même version.
  2. Si pour une raison ou une autre vous ne pouvez pas lancer le script CLI, vous pouvez utiliser le script web. Ce script est lancé depuis un navigateur web en chargeant une URL qui ressemble à celle-ci : http://mon.site-moodle.fr/admin/cron.php. On peut utiliser pour cela un navigateur web en ligne de commande (par exemple wget), et la commande à lancer ressemblera donc à quelque chose comme
    /usr/bin/wget http://mon.site-moodle.fr/admin/cron.php
    Cette méthode a l'avantage de pouvoir être lacée *depuis n'importe où*. Si vous n'arrivez pas à configurer le cron sur votre serveur, vous pouvez ainsi le lancer depuis une autre machine.

Trouver l'emplacement où indiquer la commande

Cette étape dépend du serveur que vous utilisez. Il vous faut donc lire la documentation de votre plateforme ou de votre hébergeur. La plupart du temps, mettre en place le cron de Moodle consiste à déterminer la bonne commande à lancer (voir ci-dessus) et à l'ajouter, avec l'horaire adéquat, à un fichier prévu pour cela, soit en le modifiant directement, soit via une interface spécifique.

Si vous utilisez le script CLI, vous devez également vous assurer que le processus cron est lancé avec le bon utilisateur. Il n'est en revanche pas nécessaire de s'en soucier avec la version web.

Exemple : installation du cron sur Linux Ubuntu/Debian. On suppose que l'utilisateur est connecté en tant que root.

Utiliser la commande crontab pour ouvrir la fenêtre de l'éditeur de crontab pour l'utilisateur www-data. Il s'agit de l'utilisateur qui possède le processus Apache (le serveur web) sur les serveurs Debian

$ crontab -u www-data -e

Cette commande ouvre la fenêtre de l'éditeur. Pour configurer le script cron de sorte à le lancer toutes les minutes, ajouter la ligne :

*/1 * * * * /usr/bin/php  /chemin/de/moodle/admin/cli/cron.php >/dev/null

Remarque : la fin de la commande >/dev/null envoie à la poubelle la sortie de la commande et évite que vous receviez un courriel toutes les minutes.

Mettre en place le cron sur votre système

Suivant le type de votre serveur :

Voici des instructions supplémentaires pour des hébergeurs spécifiques (vérifiez qu'elle sont bien à jour) :

Utilisation de services cron tiers

Au lieu d'utiliser votre propre serveur pour lancer le cron, vous pouvez utiliser un service tiers (appelé parfois webcron) :

  • cron-job.org - un service gratuit (le cron toutes les minutes est possible).
  • EasyCron - un fournisseur de cron sur le web qui permet de se passer d'un crontab pour lancer les tâches cron.

Réglages du cron dans Moodle

Certains réglages de Moodle permettent de contrôler divers aspects de l’opération cron :

  • Réglages du cron - Réglages du mot de passe du processus cron et du script cron en ligne de commande.

Nouveauté
Moodle
2.7

Cron depuis Moodle 2.7

Le cron a été modifié de manière majeure dans Moodle 2.7, et permet l'exécution de tâches programmées et ad hoc (voir MDL-25499). Les bénéfices de ces changements sont les suivants :

  • la programmation de chaque tâche peut être configurée par l'administrateur. Voir Tâches programmées ;
  • les tâches peuvent tourner en parallèle ;
  • les processus cron utilisent des verrous pour éviter qu'une tâche soit lancée simultanément par des processus différents.

En conséquence, le cron peut être lancé de manière beaucoup plus fréquente (sans risque de blocage), ce qui permet par exemple d'envoyer les messages des forums plus tôt. Il est recommandé de l'adapter à une fréquence d'une fois par minute.

Cron distant

L'utilisation de la version web du cron permet de lancer le cron depuis une machine différente de votre serveur Moodle. Par exemple, on pourra utiliser le cron d'une machine Unix pour lancer la version web du cron d'un Moodle installé sur un serveur Windows. Il faudra que l'utilisation via le web soit autorisée.

Pour savoir si le cron a bien été lancé récemment, il suffit de vous rendre avec un compte administrateur à l'adresse : http://mon.moodle/admin/index.php, ou en passant par « Administration du site > Notifications ».

cron OK.jpg   cron pas OK.jpg
Le cron a bien été lancé
(Attention : la date indiquée concerne la recherche des mises à jour !)
   Le cron n'a pas été exécuté depuis au moins 24 heures, voire...
n'a jamais été lancé !

Débogage des Tâches programmées

Parfois, une tâches programmées particulière peut ne pas fonctionner correctement. Dans les versions de Moodle antérieures à la 2.7 - toute tâche programmées qui déclenchait des erreurs empêchait le reste du CRON de fonctionner. La seule solution pour vérifier si le CRON arrivait à chaque fois à son terme était d'ajouter un mécanisme de vérification automatique exploitant la sortie du CRON en cours (par exemple, en recherchant la chaîne "Cron terminé à").

Dans Moodle 2.7 et suivants, une seule tâche programmées défaillante n'empêchera plus les tâches restantes de s'achever. Lorsqu'une tâche programmée échoue, elle est marquée comme un échec et programmée pour être réessayée. Si la tâche continue d'échouer, la prochaine tâche programmée sera annulée jusqu'à ce qu'elle soit tentée au maximum une fois toutes les 24 heures. Mais en consultant la page d'administration des Tâches programmées, vous pouvez voir si une tâche est encore en échec (elle aura un délai d'échec non nul ce qui représente le nombre de secondes à attendre avant de réessayer une tâche échouée). Un moyen simple de déboguer une tâche défaillante est de l'exécuter immédiatement en utilisant le gestionnaire de tâches programmées et de surveiller sa sortie.

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)

You can also wire this status report up to tools like Icinga / Nagios using the Check API (https://docs.moodle.org/dev/Check_API) cli commands or with the help of plugins like https://github.com/catalyst/moodle-tool_heartbeat.

/admin/cli/checks.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.:

 * * * * * /usr/bin/php  /path/to/moodle/admin/cli/cron.php 2>&1 | /usr/bin/logger ...

Lenteurs sur les tâches adhoc

Chaque fois que le CRON est exécuté, les « tâches ad hoc » sont également exécutées une fois les tâches programmées sont toutes terminées. Alors que les tâches programmées peuvent être exécutées au maximum une fois par minute, les tâches ad hoc peuvent être mises en file d'attente à tout moment, et généralement, vous souhaitez qu'elles soient traitées le plus rapidement possible et ne pas devoir attendre que les tâches programmées soient exécutées en premier. Si vous n'exécutez que la commande principale admin/cli/cron.php, non seulement il se peut que vous deviez attendre que toutes les tâches programmées se terminent en premier, mais même si elles sont terminées, vous devrez peut-être attendre la minute suivante pour que CRON redémarre afin qu'elle soit traitée.

Au lieu de cela, vous pouvez utiliser un ou plusieurs processus de « tâches ad hoc » qui fonctionnent en parallèle avec le processus CRON principal.

Exemple :

 * * * * * /usr/bin/php  /chemin/vers/dossier/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59
 * * * * * /usr/bin/php  /chemin/vers/dossier/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59
...

À partir de Moodle 3.9, l'option keep-alive ("garder en vie") agit comme un démon. Ainsi, lorsque la file d'attente est vide, plutôt que de se terminer, celui-ci attend que de nouvelles tâches soient mises en file d'attente afin de pouvoir commencer le traitement dès que 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:

 * * * * * /usr/bin/php  /path/to/moodle/admin/cli/cron.php
 * * * * * /usr/bin/php  /path/to/moodle/admin/cli/cron.php
 * * * * * /usr/bin/php  /path/to/moodle/admin/cli/cron.php
...
 * * * * * /usr/bin/php  /path/to/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59
 * * * * * /usr/bin/php  /path/to/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59
 * * * * * /usr/bin/php  /path/to/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59
...

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

Ou dans config.php :

$CFG->task_scheduled_concurrency_limit = 20; // Defaults to 3
$CFG->task_adhoc_concurrency_limit = 50; // Defaults to 3

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:

Dans config.php :

$CFG->task_concurrency_limit = [
    'core\task\course_backup_task' => 25,
    'core_course\task\course_delete_modules' => 5,
];

Voir aussi

Discussions sur les forums d'assistance Moodle (en anglais) :