Diagnostiquer une tâche cron Linux qui ne se lance pas

Une commande fonctionne dans votre terminal, puis disparaît dès que vous la mettez dans la crontab. Le problème vient rarement de cron lui-même. Le service lance votre ligne avec peu de variables, un répertoire de travail différent et parfois un autre utilisateur.

Avant de modifier dix fois la planification, reproduisez la commande avec le même chemin, le même compte et une sortie de log lisible. C’est la façon la plus rapide de savoir si vous avez un souci de syntaxe, de droits ou d’environnement.

Commencez par lire la crontab du bon compte

La crontab de votre session n’est pas forcément celle qui doit exécuter la tâche. Vérifiez d’abord votre table, puis celle du compte de service si le script doit tourner sous www-data, backup ou un autre utilisateur.

crontab -l
sudo crontab -u backup -l

Une ligne utilisateur contient cinq champs de temps, puis la commande. Dans /etc/crontab et /etc/cron.d/, il faut un champ utilisateur supplémentaire. Copier une ligne prévue pour /etc/crontab dans crontab -e décale tout et empêche l’exécution attendue.

# Crontab de l'utilisateur courant, tous les jours à 02:15
15 2 * * * /usr/local/bin/sauvegarde.sh

# /etc/crontab, même horaire, avec l'utilisateur explicite
15 2 * * * backup /usr/local/bin/sauvegarde.sh

Utilisez des chemins absolus et définissez l’environnement utile

Cron n’ouvre pas votre terminal interactif. Il ne lit donc pas forcément votre .bashrc, votre alias, votre répertoire courant ni le PATH que vous utilisez à la main. Écrivez le chemin complet du script et de ses binaires importants.

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

15 2 * * * /usr/bin/python3 /opt/maintenance/nettoyage.py

Si votre script dépend d’une variable, définissez-la dans le script ou juste avant la commande. Évitez d’y placer un mot de passe ou un jeton: une crontab peut être lue par l’administrateur, copiée dans une sauvegarde ou affichée pendant un diagnostic. Pour une configuration plus complète, le guide sur les variables d’environnement Linux aide à isoler ce que reçoit réellement un processus.

Gardez la sortie et l’erreur dans un journal

Une tâche silencieuse est pénible à diagnostiquer. Redirigez la sortie standard et les erreurs vers un fichier que vous pouvez lire, au moins pendant le test. Créez le dossier au préalable et vérifiez qu’il appartient bien au compte qui lance cron.

15 2 * * * /usr/local/bin/sauvegarde.sh >> /var/log/backup-cron.log 2>&1

Après le créneau prévu, contrôlez les dernières lignes:

sudo tail -n 50 /var/log/backup-cron.log

Selon la distribution, les traces de cron se trouvent dans le journal systemd, /var/log/syslog ou /var/log/cron. Cherchez le service et la période concernée au lieu de relire tout le journal.

sudo journalctl -u cron --since "today 02:00" --until "today 03:00"
sudo grep CRON /var/log/syslog | tail -n 50

Le service peut s’appeler crond sur certaines distributions. Utilisez systemctl status cron puis systemctl status crond pour identifier le bon nom. Si votre besoin est de lancer un script avec journal, dépendances et rattrapage après un arrêt, un timer systemd donne souvent de meilleurs contrôles que cron.

Rejouez exactement la commande avant de toucher au planning

Copiez la commande dans un terminal sous le même utilisateur. Puis lancez-la avec un environnement réduit. Cette seconde étape révèle vite une dépendance à un alias, à un PATH trop large ou au dossier depuis lequel vous étiez connecté.

sudo -u backup /usr/local/bin/sauvegarde.sh
sudo -u backup env -i PATH=/usr/bin:/bin SHELL=/bin/sh /usr/local/bin/sauvegarde.sh

Contrôlez aussi les droits du script, de ses dossiers parents et du fichier de log. Un fichier exécutable ne suffit pas si le compte cron ne peut pas traverser /opt/maintenance ou écrire dans /var/log.

namei -l /usr/local/bin/sauvegarde.sh
ls -l /usr/local/bin/sauvegarde.sh
sudo -u backup test -w /var/log && echo "écriture possible"

Évitez deux exécutions simultanées

Une tâche qui dure plus longtemps que son intervalle peut se lancer une seconde fois. Une sauvegarde, une synchronisation ou une maintenance de base de données peut alors se marcher dessus. Ajoutez un verrou flock lorsque ce risque existe.

*/10 * * * * /usr/bin/flock -n /run/lock/sauvegarde.lock /usr/local/bin/sauvegarde.sh >> /var/log/backup-cron.log 2>&1

Avec -n, la seconde exécution s’arrête si le verrou est déjà pris. Le fonctionnement et les limites de ce mécanisme sont détaillés dans notre article sur flock sous Linux.

Quand la commande, le compte, les droits et le journal sont cohérents, cron devient beaucoup moins mystérieux. Gardez la ligne simple, testez-la hors cron, puis laissez-la passer un cycle complet avant de conclure.