Cron

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 :

• Cron sur Unix ou Linux - Services cron sur les systèmes d'exploitation Unix et Linux.
• Cron sur Apple OS X - Utilisez le service crontab comme dans Cron sur Unix ou Linux. Il est cependant aussi possible d'effectuer ceci à la façon OS X, à l'aide de launchd. Pour cela voir Cron sur Mac OS X.
• Cron sous Windows - Services cron sous Windows
• Cron avec des services d'hébergement web- Services cron dans divers exemples d'hébergement web.

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

• Cron sur des serveurs mutualisés 1and1

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

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

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.

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

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:

* * * * * /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

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:

config.php: $CFG->task_concurrency_limit = [

   'core\task\course_backup_task' => 25,
   'core_course\task\course_delete_modules' => 5,

];

Voir aussi

• Article Wikipedia sur le cron

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

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