Capturer la sortie de cron

Introduction

Les tâches cron s'exécutent en arrière-plan, sans être rattachées à une session de terminal. C'est idéal pour l'automatisation, mais cela complique le débogage : si un script échoue, vous ne verrez pas le message d'erreur à l'écran.

Lorsqu'une tâche cron produit une sortie, le système essaie traditionnellement de l'envoyer par e-mail à l'utilisateur. Sur de nombreux serveurs modernes, conteneurs ou environnements de formation, l'envoi d'e-mails n'est pas configuré. La sortie peut donc tout simplement disparaître si vous ne la redirigez pas vous-même.

C'est l'une des raisons pour lesquelles cron semble souvent déroutant aux débutants : la tâche peut s'exécuter exactement comme prévu, mais les messages d'erreur ne sont pas visibles dans le terminal depuis lequel la crontab a été créée. L'automatisation en arrière-plan nécessite une journalisation explicite.

Dans ce lab, vous apprendrez à capturer cette sortie « silencieuse » afin de déboguer les échecs. Vous allez :

Simuler un échec : créer une tâche cron qui produit forcément une erreur.
Rediriger l'erreur standard : utiliser l'opérateur 2> pour capturer les messages d'erreur.
Analyser les journaux : lire la sortie capturée pour vérifier la cause de l'échec.

Créer une tâche cron qui échoue

Commencez par créer volontairement une tâche incorrecte afin de simuler un échec. Vous allez demander à cron d'afficher le contenu d'un répertoire qui n'existe pas.

Ouvrez la crontab de votre utilisateur :

crontab -e

Placez-vous à la fin du fichier, sous les éventuels commentaires, puis ajoutez cette ligne :

* * * * * ls /this/directory/does/not/exist

Détails de la configuration :

Planification : * * * * * (exécution toutes les minutes).
Commande : ls ... (tentative d'affichage d'un chemin qui n'existe pas).

Enregistrez le fichier et quittez l'éditeur.

Attendez maintenant au moins une minute.

Observez votre terminal. ...

Rien ne s'affiche à l'écran. Il s'agit d'un échec silencieux. La commande s'est exécutée, a échoué et a généré un message d'erreur, mais ce message n'avait aucune destination et a donc été supprimé.

Ce silence ne signifie pas que « rien ne s'est passé ». Il signifie que le processus n'était rattaché à aucun terminal interactif. Comprendre cette différence est essentiel pour déboguer les tâches planifiées.

Rediriger l'erreur standard (stderr)

Pour voir le message d'erreur, vous devez rediriger le flux d'erreur standard (stderr) vers un fichier.

Sous Linux, les descripteurs de fichiers sont numérotés comme suit :

0 : entrée standard (stdin)
1 : sortie standard (stdout)
2 : erreur standard (stderr)

L'opérateur 2> permet de rediriger le canal 2, c'est-à-dire les erreurs, vers un fichier.

Cette opération repose sur le même modèle de redirection du shell que celui étudié précédemment. Cron lance une commande, le shell gère ses descripteurs de fichiers et la redirection détermine la destination de chaque flux.

Ouvrez de nouveau votre crontab :

crontab -e

Modifiez la ligne pour obtenir exactement ceci :

* * * * * ls /this/directory/does/not/exist 2> /home/labex/project/cron_error.log

Modifications importantes :

2> : redirige le flux d'erreur.
/home/labex/project/cron_error.log : chemin absolu du fichier journal.
- Important : utilisez toujours des chemins absolus (par exemple, /home/labex/...) dans les tâches cron. Cron s'exécute dans un environnement minimal et ne sait pas à quoi correspondent ~ ou les chemins relatifs.

Cet environnement minimal est un autre concept essentiel de cron. Les tâches planifiées disposent généralement de moins de variables d'environnement, d'un PATH limité et d'aucun contexte de shell interactif. Une commande qui fonctionne manuellement peut donc échouer avec cron si elle repose sur des suppositions implicites.

Enregistrez le fichier et quittez l'éditeur.

Analyser le fichier journal

Attendez encore une minute pour que la tâche s'exécute de nouveau.

Vérifiez maintenant si le fichier journal contient l'erreur :

cat ~/project/cron_error.log

Vous devriez voir le message d'erreur enregistré clairement : ls: cannot access '/this/directory/does/not/exist': No such file or directory

Nettoyage : il est déconseillé de laisser des tâches défaillantes s'exécuter en arrière-plan.

Ouvrez crontab -e.
Supprimez la ligne associée à ce lab.
Enregistrez le fichier et quittez l'éditeur.

Vous avez maintenant débogué avec succès une tâche en arrière-plan en capturant sa sortie d'erreur.

Dans les opérations réelles, de nombreux problèmes liés à cron sont dus à l'environnement, à des chemins manquants ou aux permissions, plutôt qu'à une erreur de syntaxe de la commande. La sortie capturée est souvent le moyen le plus rapide de déterminer la catégorie du problème rencontré.

Résumé

Dans ce lab, vous avez appris à gérer la sortie des tâches cron exécutées en arrière-plan :

Le problème : les tâches cron échouent silencieusement si leur sortie n'est pas gérée.
La solution : utiliser la redirection de l'erreur standard (2>) pour capturer les messages d'échec.
Bonne pratique : toujours journaliser la sortie des tâches automatisées afin de pouvoir les déboguer en cas d'échec.

Cette technique (2> error.log) est essentielle pour maintenir des scripts d'automatisation fiables dans tout environnement Linux.