Où sont enregistrées les erreurs cron?
Si je configure les travaux cron de manière incorrecte, ils semblent échouer en silence. Où dois-je rechercher un journal des erreurs pour comprendre ce qui n'a pas fonctionné?
Comme d'autres l'ont souligné, cron vous enverra par e-mail la sortie de tout programme qu'il exécute (s'il y a une sortie). Donc, si vous n'obtenez aucune sortie, il y a essentiellement trois possibilités:
crondn'a même pas pu démarrer un shell pour exécuter le programme ou envoyer un e-mailcronda rencontré des problèmes pour envoyer la sortie ou le courrier a été perdu.- le programme n'a produit aucune sortie (y compris les messages d'erreur)
Le cas 1. est très improbable, mais quelque chose aurait dû être écrit dans les journaux cron. Cron possède sa propre fonction syslog réservée, vous devriez donc jeter un œil à /etc/syslog.conf (ou le fichier équivalent dans votre distribution) pour voir où les messages de l'installation cron sont envoyés. Les destinations populaires incluent /var/log/cron, /var/log/messages et /var/log/syslog.
Dans le cas 2., vous devriez inspecter les journaux du démon de messagerie: les messages du démon Cron apparaissent généralement à partir de root@yourhost. Vous pouvez utiliser un MAILTO=... ligne dans le fichier crontab pour que cron envoie un e-mail à une adresse spécifique, ce qui devrait faciliter la grep des journaux du démon de l'expéditeur. Par exemple:
[email protected]
00 15 * * * echo "Just testing if crond sends email"
Dans le cas 3., vous pouvez tester si le programme a réellement été exécuté en ajoutant une autre commande dont vous pouvez facilement vérifier l'effet: par exemple,
00 15 * * * /a/command; touch /tmp/a_command_has_run
afin que vous puissiez vérifier si crond a réellement exécuté quelque chose en regardant le mtime de /tmp/a_command_has_run.
Vous pouvez toujours envoyer explicitement la sortie du travail dans un fichier journal:
0 8 * * * /usr/local/bin/myjob > /var/log/myjob.log 2>&1
Gardez à l'esprit que cela remplacera le comportement de messagerie qui a été mentionné précédemment, car crond iself ne recevra aucune sortie du travail. Si vous voulez conserver ce comportement, vous devriez regarder dans tee (1).
Si vous ne voyez pas les e-mails, vous risquez de spammer root @ yourcompany avec des erreurs qui peuvent être assez gênantes pour les personnes qui utilisent ce compte pour la surveillance. Essayez d'envoyer la sortie à Syslog à la place:
*/5 * * * * yourcronjob 2>&1 | /usr/bin/logger -t yourtag
Ensuite, attendez que le cronjob s'exécute et recherchez l'erreur dans/var/log/messages (ou /var/log/user.log sur certains systèmes).
Cela fonctionne très bien pour les messages d'erreur de 1 à 2 lignes, tels que "yourcronjob: commande introuvable". Il utilise également votre infrastructure syslog existante (Logrotation, syslogging central, Splunk, etc.). Il réduit également le spam par e-mail à la racine.
Ce n'est peut-être pas une bonne solution si votre cronjob génère des centaines de lignes de sortie.
Vous devez recevoir des e-mails de crond lorsque le travail ne s'exécute pas ou lorsque le travail retourne un code de sortie différent de zéro. Essayez de taper:
$ mailx
à l'invite de commande.
mailx(1) est le programme de lecture de courrier de base sur la plupart des systèmes Unixlike. Il est très primitif par rapport aux normes modernes, mais vous pouvez compter sur lui pour qu'il soit toujours disponible. D'autres meilleurs agents de messagerie peuvent être disponibles, mais il y en a suffisamment pour que vous ne sachiez jamais lequel est installé sur une machine aléatoire que vous utilisez.
Notez que sauf si vous avez configuré votre système en tant que serveur de messagerie Internet, ce sous-système de messagerie est utilisé uniquement sur la machine. Vous pouvez envoyer et recevoir des e-mails d'autres utilisateurs sur la machine, mais vous ne pourrez peut-être pas envoyer d'e-mails au monde entier, et les e-mails du monde extérieur ne pourront certainement pas arriver sur votre machine.
La configuration cron par défaut vous enverra un mail avec la sortie de votre programme. Si cela échoue, vous pouvez essayer d'encapsuler votre programme défaillant dans un script Shell qui garantit que le programme n'échoue pas, et vous pouvez enregistrer davantage la sortie.
Il s'agit d'un paramètre configurable sur certaines implémentations cron.
Cron enregistre les informations de base dans /var/log/messages, mais envoie toute sortie de programme à l'utilisateur appelant.
Je suis tombé sur ce fil il y a quelques années, rencontrant les mêmes problèmes et je suis récemment tombé sur une solution aux cas mentionnés ci-dessus par Ricardo. L'absence d'un e-mail est difficile à détecter (comme vous l'avez mentionné) et vous ne voulez certainement pas spammer votre e-mail root @ yourcompany. Si vous êtes intéressé, consultez deadmanssnitch.com. . Cet outil semble résoudre les cas susmentionnés. Semble assez simple à utiliser - il suffit d'ajouter le peu de code que l'outil vous donne à votre cronjob. Si votre tâche ne s'exécute pas à un niveau interne spécifié, vous serez alerté. Si votre travail recommence, vous serez également alerté.
J'utilise vixie-cron, donc je ne sais pas si cela s'applique à tout. Mais j'ai un dead.letter fichier contenant toute la sortie du travail.
Dans mon /root/ dossier que j'ai crons.cron que j'ai défini comme mon crontab en exécutant crontab /root/crons.cron. dead.letter sera créé dans /root/ ainsi que.
Modifier Je viens de Google dead.letter, et c'est un courrier non distribuable. Cela n'a apparemment rien à voir avec cron. Si vous n'avez pas configuré correctement le courrier (comme moi), vous aurez le fichier.
Une autre astuce utile consiste à voir quels scripts sont réellement exécutés.
Cela se fait avec run-parts -v --test /etc/cron.hourly/
> /etc/cron.hourly//logrotate
Si votre script n'apparaît pas, il ne sera pas exécuté.
Ce btw ne fonctionne que pour les scripts installés dans le /etc/cron.hourly répertoire. Il ne vous montre pas les éléments définis dans votre crontab.
Pour les débutants, cela pourrait être difficile à déboguer. Veillez à ne pas échanger les valeurs des minutes et des heures. La minute vient en premier, puis l'heure. Lorsque vous fournissez des valeurs inférieures à 12 pour chacune, il les accepte mais peut ne pas fonctionner comme prévu ou pas du tout.