Vérifiez si les programmes que vous exécutez avec cron ont leurs propres fichiers journaux. S'ils ne le font pas, mais écrivent leur sortie sur les sorties standard, vous pouvez les rediriger vers des fichiers ou vous les envoyer par courrier électronique. À l'intérieur de crontabs, la redirection standard du shell fonctionne.
Par exemple. pour rediriger la sortie d'erreur de some_job.sh à some_job.err et rejeter la sortie standard (c'est-à-dire l'envoyer à /dev/null ) ajoutez la redirection suivante à votre crontab
33 3 * * * /path/to/some_job.sh 1> /dev/null 2> /other/path/to/some_job.err
ou de vous l'envoyer par courrier (si mail est disponible)
33 3 * * * /path/to/some_job.sh 1> /dev/null 2>&1 | mail -s "cron output" [email protected]
La plupart des démons cron sur les plates-formes avec lesquelles j'ai travaillé envoient automatiquement par e-mail le stdout/stderr des tâches cron de l'utilisateur à l'utilisateur dont crontab provient la tâche. J'oublie ce qui arrive à l'ensemble du système (tâches cron non spécifiques à l'utilisateur de /etc/crontab). Le fait est que les gens ne configurent plus toujours un démon de messagerie (c'est-à-dire un agent de transfert de courrier (MTA) comme sendmail, qmail ou postfix) sur la plupart des systèmes d'exploitation de type Unix. Ainsi, les e-mails de sortie de la tâche cron meurent simplement dans un dossier de spool de courrier local quelque part s'ils obtiennent même cela loin. Donc, une réponse pourrait être simplement de lancer votre démon de messagerie, et peut-être de vous assurer que vous disposez d'un fichier ~/.forward pour transférer votre courrier local vers votre "vrai" compte de messagerie.
Si vous souhaitez que vos tâches écrivent dans des fichiers journaux spécifiques, vous pouvez utiliser la redirection de sortie standard comme suggéré par @honk, ou, en supposant que votre tâche cron est un script shell, votre script peut appeler logger(1) ou syslog(1) ou quel que soit l'autre outil de ligne de commande fourni par votre système d'exploitation pour envoyer des messages arbitraires à syslog. Ensuite, vous pouvez utiliser les méthodes intégrées de votre système d'exploitation pour configurer quels types de messages sont enregistrés où, peut-être en modifiant /etc/syslog.conf.
La plupart de mes tâches cron invoquent des scripts bash que j'ai écrits spécifiquement dans le but d'être démarrés par cron pour une raison particulière. Dans ceux-ci, en particulier lorsque je les écris et les débogue pour la première fois, j'aime utiliser "set -vx" de bash pour que la forme non développée et développée de chaque ligne du script shell soit écrite sur stdout avant son exécution. Notez que les scripts shell lancés à partir de cron sont considérés comme des shells non interactifs et sans connexion, de sorte que vos scripts de démarrage shell standard tels que .bashrc et .profile ne sont pas exécutés. Si vous utilisez bash et souhaitez que bash exécute un script de démarrage, vous devez définir une variable d'environnement "BASH_ENV=/path/to/my/startup/script" dans votre crontab avant la ligne où vous définissez le travail.
Les tâches que cron exécute sont responsables de leur propre journalisation.