Cron qui ne s’exécute pas : causes et alerte
Vous venez de découvrir qu’un cron ne s’exécute pas depuis des jours. Voici les causes les plus fréquentes, comment les vérifier, et surtout comment faire pour que ce soit le monitoring, et pas un utilisateur, qui vous le dise la prochaine fois.
Les causes les plus fréquentes
Section intitulée « Les causes les plus fréquentes »- Le service cron est arrêté. Vérifiez
systemctl status cron(oucrondselon la distribution). Dans un conteneur, il n’y a souvent aucun démon cron : il faut le lancer, ou utiliser un ordonnanceur externe. - La syntaxe de la ligne est fausse. Cinq champs puis la commande ; un
%dans la commande doit être échappé (\%), sinon cron le prend pour un saut de ligne. Dans/etc/cron.d/, une sixième colonne indique l’utilisateur. - Le fichier crontab ne se termine pas par un retour à la ligne. Une dernière ligne sans saut de ligne peut être ignorée.
- L’environnement de cron n’est pas celui de votre shell. Le
PATHest minimal, les variables de votre profil n’existent pas, le répertoire courant n’est pas celui que vous croyez. Utilisez des chemins absolus et définissez les variables dans le script. - Les droits sont mauvais. Le script n’est pas exécutable (
chmod +x), ou l’utilisateur du cron n’y a pas accès. Un utilisateur listé danscron.deny, ou absent decron.allow, ne peut pas planifier de tâche. - Le nom du fichier est ignoré. Dans
/etc/cron.daily/et ses voisins,run-partsignore les fichiers dont le nom contient un point. - Le fuseau horaire ou l’heure d’été décalent ou font sauter l’exécution. Une tâche à 2 h 30 peut ne jamais se lancer le jour du passage à l’heure d’été.
- Le job échoue, et l’erreur part dans le courrier local. Cron envoie la sortie des commandes à l’utilisateur par e-mail local, que personne ne lit. Redirigez la sortie vers un fichier, ou renseignez
MAILTO.
Pour diagnostiquer : regardez les journaux de cron (journalctl -u cron ou /var/log/syslog), lancez la commande à la main avec env -i pour simuler un environnement vide, et ajoutez une redirection >> /var/log/mon-job.log 2>&1.
La vraie question : comment l’avoir su plus tôt ?
Section intitulée « La vraie question : comment l’avoir su plus tôt ? »Toutes ces pannes ont la même signature : il ne se passe rien. Aucun journal ne s’écrit, aucune erreur ne remonte. Seul un dead man’s switch les voit : le job envoie un signal à chaque exécution réussie, et un service vous alerte quand le signal manque.
0 2 * * * /usr/local/bin/backup.sh && curl -fsS -m 10 --retry 3 https://app.silencewatch.com/p/<clé-de-ping>Avec cette seule ligne, chacune des huit causes ci-dessus déclenche une alerte à l’échéance suivante plus le délai de grâce. Voir le monitoring de cron et les exemples.
Questions fréquentes
Section intitulée « Questions fréquentes »Pourquoi mon cron ne s’exécute pas alors que la commande marche à la main ?
Presque toujours à cause de l’environnement : cron lance la commande avec un PATH minimal et sans les variables de votre profil. Utilisez des chemins absolus et définissez les variables nécessaires dans le script.
Comment voir si cron a lancé mon job ?
Consultez les journaux de cron : journalctl -u cron, ou /var/log/syslog selon la distribution. Pour être alerté automatiquement quand un job ne se lance pas, ajoutez un appel de heartbeat à la fin de la commande et surveillez-le.
Pourquoi un cron ne se lance pas lors du changement d’heure ?
Une heure qui n’existe pas le jour du passage à l’heure d’été (par exemple 2 h 30) peut faire sauter l’exécution. Planifiez les jobs importants hors de cette plage, ou en UTC.