Capture de la sortie·MAILTO·checklist de vérification des journaux
cron échoue le plus souvent en silence. Si votre expression est correcte selon cet outil mais que la tâche ne tourne toujours pas, le problème vient probablement non pas de l'expression mais de l'environnement d'exécution. Voici, dans l'ordre, comment cerner la cause.
Enregistrez la sortie dans un fichier. cron envoie par défaut la sortie standard et l'erreur standard de la tâche par e-mail, mais si la messagerie n'est pas configurée, elles disparaissent purement et simplement. En ajoutant >> /var/log/myjob.log 2>&1 à la suite de la commande, vous consignez à la fois stdout et stderr dans un fichier journal et pouvez vérifier immédiatement ce qui s'est passé.
Recevez des notifications avec MAILTO. En plaçant MAILTO="you@example.com" en haut du crontab, la sortie et les erreurs de la tâche sont transmises à cette adresse. C'est la protection la plus simple contre les échecs silencieux. À l'inverse, si vous ne voulez pas d'e-mail, videz-le avec MAILTO="".
Consultez les journaux système. Sur les distributions de type Debian et Ubuntu, utilisez grep CRON /var/log/syslog ; en environnement systemd, utilisez journalctl -u cron (ou crond) pour vérifier si cron a bien déclenché la tâche. La distinction importante ici est que « avoir tenté l'exécution » et « le script a réussi » sont deux choses différentes.
Enfin, voici une checklist des causes fréquentes. ① Avez-vous spécifié toutes les commandes et tous les fichiers en chemin absolu ? ② Avez-vous déclaré le PATH nécessaire dans le crontab ? ③ Le script a-t-il les droits d'exécution (chmod +x) ? ④ Avez-vous placé la tâche dans le crontab du bon utilisateur (le crontab de root et celui d'un utilisateur ordinaire sont distincts) ? Vérifiez ces quatre points, puis validez de nouveau l'expression elle-même avec cet interpréteur.