Où les erreurs cron sont-elles enregistrées?

Si je configure les crontâches de manière incorrecte, elles semblent échouer en silence. Où devrais-je chercher un journal des erreurs pour comprendre ce qui ne va pas?

Comme d'autres l'ont fait remarquer, cronvous enverrons par courrier électronique le résultat de tout programme qu'il exécute (le cas échéant). Donc, si vous n’obtenez aucune sortie, il existe essentiellement trois possibilités:

1. crond ne pouvait même pas démarrer un shell pour exécuter le programme ou envoyer un courrier électronique
2. crond eu des problèmes pour poster la sortie ou le courrier était perdu.
3. 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 a sa propre installation réservée syslog, vous devriez donc jeter un coup d'œil /etc/syslog.conf(ou le fichier équivalent dans votre distribution) pour voir où les messages de cette installation cronsont envoyés. Les destinations populaires incluent /var/log/cron, /var/log/messageset /var/log/syslog.

Dans le cas 2., vous devriez inspecter les journaux du démon de courrier: les messages du démon Cron apparaissent généralement de root@yourhost. Vous pouvez utiliser une MAILTO=...ligne du fichier crontab pour que cron envoie un courrier électronique à une adresse spécifique, ce qui facilitera la sauvegarde des journaux du démon de messagerie. Par exemple:

MAILTO=my.offsite.email@example.org
00 15 * * *  echo "Just testing if crond sends email"

Dans le cas 3., vous pouvez vérifier si le programme a bien é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 cronda réellement exécuté quelque chose en regardant l'heure de /tmp/a_command_has_run.

Vous pouvez toujours explicitement envoyer le résultat 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 mentionné précédemment, car crond iself ne recevra aucune sortie du travail. Si vous voulez garder 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 l’exécution du travail cron et recherchez l’erreur dans / var / log / messages (ou dans /var/log/user.log sur certains systèmes).

Cela fonctionne très bien pour les messages d’erreur qui ne comptent que 1 ou 2 lignes, tels que "yourcronjob: command not found". Il utilise également votre infrastructure syslog existante (Logrotation, Syslogging central, Splunk, etc.). Il réduit également le spam par courrier électronique à la racine.

Ce n'est peut-être pas une bonne solution si votre tâche cron génère des centaines de lignes de sortie.

La configuration par défaut de cron 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 garantissant que le programme n'échoue pas, et vous pouvez également enregistrer la sortie.

C'est un paramètre configurable sur certaines implémentations de cron.

Vous devez recevoir un courrier électronique crondlorsque la tâche ne parvient pas à s'exécuter ou qu'elle renvoie un code de sortie différent de zéro. Essayez de taper:

$ mailx

à l'invite de commande.

mailx(1)est le programme de base de lecture de courrier sur la plupart des systèmes Unixlike. Il est très primitif par rapport aux normes modernes, mais vous pouvez compter sur lui pour être toujours disponible. D'autres agents de messagerie plus performants peuvent être disponibles, mais il y en a suffisamment pour que vous ne sachiez jamais lequel est installé sur un ordinateur quelconque que vous utilisez par hasard.

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 des emails à d'autres utilisateurs de la machine et les recevoir, mais vous ne pourrez peut-être pas envoyer d'e-mails au monde entier, et les emails des autres pays ne pourront certainement pas accéder à votre machine.

Cron enregistre les informations de base dans /var/log/messages, mais envoie toute sortie du programme à l'utilisateur invoquant.

Je suis tombé sur ce fil il y a quelques années, éprouvant les mêmes problèmes et je viens tout juste de trouver une solution aux cas susmentionnés de Ricardo. L'absence de courrier électronique est difficile à détecter (comme vous l'avez mentionné) et vous ne voulez certainement pas spammer votre courrier électronique root @ yourcompany. Si vous êtes intéressé, rendez- vous sur deadmanssnitch.com. . Cet outil semble résoudre les cas susmentionnés. Cela semble assez simple à utiliser - ajoutez simplement le peu de code que l'outil vous donne pour votre travail cron. Si votre travail ne s'exécute pas sur un serveur interne spécifié, vous en serez averti. 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.letterfichier qui contient toute la sortie du travail.

Dans mon /root/dossier, j'ai crons.cronce que j'ai défini comme ma crontab en cours d'exécution crontab /root/crons.cron. dead.lettersera créé dans /root/ainsi.

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é le courrier correctement (comme moi), vous aurez le fichier.

Pour les débutants, cela pourrait être difficile à déboguer. Veillez à ne pas intervertir les valeurs des minutes et des heures. La minute vient en premier, puis l'heure. Lorsque vous fournissez des valeurs inférieures à 12 pour chaque valeur, elles seront acceptées mais risquent de ne pas fonctionner correctement ou pas du tout.