cron (Tâches planifiées)

systemctl status cron

Sur les systèmes Red Hat ou CentOS, le service s’appelle `crond` :

systemctl status crond

Si cron ne tourne pas, démarrez le service avec :

sudo systemctl start cron
sudo systemctl enable cron

2. Affichez vos tâches cron actuelles

La commande `crontab -l` affiche la liste des tâches planifiées pour l’utilisateur actuel.

crontab -l

S’il n’y a pas encore de tâches, vous obtenez une sortie vide ou un message indiquant qu’aucun crontab n’est configuré.

3. Modifiez votre crontab

Ouvrez votre crontab dans l’éditeur par défaut pour ajouter ou modifier des tâches.

crontab -e

À la première utilisation, le système choisit un éditeur — généralement `nano` ou `vi`. Vous pouvez choisir explicitement un éditeur :

EDITOR=nano crontab -e

4. Comprenez le format à cinq champs

Chaque ligne d’un crontab comporte cinq champs de temps suivis de la commande. Les champs sont : minute, heure, jour du mois, mois, jour de la semaine.

minute heure jour-du-mois mois jour-de-la-semaine commande

Un exemple de ligne qui exécute un script chaque jour à 02h00 :

0 2 <em> </em> * /backup/scripts/daily.sh

Les astérisques signifient « chaque » — donc chaque jour du mois, chaque mois, chaque jour de la semaine.

5. Ajoutez une tâche

Ajoutez une ligne à votre crontab pour la tâche que vous voulez planifier. Utilisez toujours des chemins complets vers les commandes et les scripts, car les tâches cron tournent hors d’un shell interactif et le `PATH` est limité.

0 2 <em> </em> * /usr/bin/backup-script.sh > /var/log/backup.log 2>&1

Cette ligne exécute le script chaque jour à 02h00 et écrit à la fois stdout et stderr vers `/var/log/backup.log`. Sans redirection, cron envoie la sortie par e-mail au propriétaire du crontab — sur les systèmes sans messagerie configurée, ces messages sont perdus.

6. Définissez des variables d’environnement si nécessaire

Comme les tâches cron n’utilisent pas de shell interactif, vous pouvez définir explicitement des variables comme `PATH` en haut de votre crontab.

PATH=/usr/local/bin:/usr/bin:/bin
SHELL=/bin/bash
0 2 <em> </em> * /usr/local/bin/backup-script.sh

Cela évite les problèmes de commandes introuvables parce qu’elles sont hors du `PATH` par défaut.

7. Utilisez les dossiers de configuration système

Pour l’administration système, vous pouvez placer des tâches dans `/etc/cron.d/`, `/etc/cron.hourly/`, `/etc/cron.daily/`, `/etc/cron.weekly/` et `/etc/cron.monthly/`. Les fichiers dans `/etc/cron.d/` utilisent le même format qu’un crontab, mais contiennent un champ utilisateur.

Créez un fichier dans `/etc/cron.d/` :

sudo nano /etc/cron.d/backup

Contenu :

0 2 <em> </em> * root /usr/local/bin/backup-script.sh

Le champ `root` indique quel utilisateur exécute la tâche. Les tâches dans `/etc/cron.daily/` et les dossiers similaires tournent respectivement chaque jour, chaque semaine et chaque mois — le format dans ces fichiers est différent : il n’y a que le chemin du script, pas de champs de temps.

8. Supprimez une tâche

Supprimez une ligne spécifique de votre crontab avec `crontab -e`, ou supprimez toutes les tâches de l’utilisateur actuel :

crontab -r

Soyez prudent : `crontab -r` supprime tout le crontab sans confirmation.

Vérification

Vérifiez que votre tâche est correctement enregistrée :

crontab -l

Vérifiez que la tâche a réellement été exécutée en consultant les journaux. Sur les systèmes Debian et Ubuntu, les journaux cron se trouvent dans `/var/log/syslog` :

grep CRON /var/log/syslog

Sur les systèmes Red Hat et CentOS, la journalisation cron se trouve dans `/var/log/cron` :

grep CRON /var/log/cron

Sur les systèmes avec systemd, vous pouvez aussi consulter le journal :

journalctl -u cron

Sur les systèmes Red Hat :

journalctl -u crond

Les lignes de journal contiennent l’heure, le nom d’utilisateur et la commande exécutée — vous voyez ainsi directement si votre tâche a tourné au bon moment.

Problèmes fréquents

La tâche ne s’exécute pas

La cause la plus courante est une erreur dans le format horaire ou un chemin complet manquant vers la commande. Vérifiez d’abord que la commande fonctionne manuellement depuis le shell, puis utilisez le chemin complet dans le crontab. Ensuite, consultez les journaux avec `grep CRON /var/log/syslog` ou `journalctl -u cron` pour voir si la tâche est prise en compte.

La sortie des tâches se perd

Sans redirection, cron envoie la sortie par e-mail au propriétaire du crontab. Sur les systèmes sans configuration de messagerie, cette sortie est perdue. Redirigez explicitement la sortie vers un fichier journal :

0 2 <em> </em> * /usr/local/bin/backup-script.sh >> /var/log/backup.log 2>&1

Variables d’environnement manquantes

Les tâches cron s’exécutent sans les variables de votre shell interactif. Définissez `PATH`, `SHELL` et les autres variables nécessaires en haut de votre crontab, ou utilisez des chemins complets vers toutes les commandes de votre script.

Cron fait partie d’Unix depuis 1975 — l’implémentation originale de Brian Kernighan dans Version 7 Unix lisait les tâches depuis `/usr/lib/crontab` et vérifiait ce fichier chaque minute, et cette vérification toutes les minutes reste toujours le cœur des implémentations modernes. La version précoce tournait comme démon en mode multi-utilisateur et exécutait toutes les tâches avec les droits du superutilisateur — un risque que les systèmes modernes évitent en faisant tourner les tâches par utilisateur. Sur les systèmes avec systemd, les timers offrent une alternative moderne, et dans les environnements conteneurisés comme Docker et Kubernetes, des orchestrateurs comme les CronJobs de Kubernetes remplacent souvent le démon cron traditionnel. Mais pour ceux qui veulent planifier des tâches de manière simple et fiable sur un serveur Linux, cron reste la fondation sur laquelle ces alternatives s’appuient finalement.