Je vois tellement de guides sur la façon de faire fonctionner crontab, mais ce dont j'ai besoin maintenant, c’est d’apprendre à
Réponses:
Vérifiez si les programmes que vous exécutez avec cron ont leurs propres fichiers journaux. Si ce n'est pas le cas, écrivez leur sortie sur les sorties standard, vous pouvez les rediriger vers des fichiers ou les envoyer par la poste. À l’intérieur de la crontabs , la redirection de shell standard fonctionne.
Par exemple, pour rediriger la sortie d'erreur de some_job.shvers some_job.erret supprimer 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 à la place (si maildisponible)
33 3 * * * /path/to/some_job.sh 1> /dev/null 2>&1 | mail -s "cron output" you@example.org
/dev/null?
some_job.shla /dev/nullsortie standard de s vers et seulement après sa sortie stderr vers la sortie standard (qui ne contient plus rien elle-même). De cette façon, seul son stderr finit dans stdout et est transmis à mail.
La plupart des démons cron sur les plates-formes avec lesquelles j'ai travaillé envoient automatiquement un courrier électronique au stdout / stderr des tâches utilisateur cron à l'utilisateur dont provient la tâche crontab. J'oublie ce qui se passe dans l'ensemble du système (tâches cron non spécifiques à l'utilisateur provenant de / etc / crontab). Le problème, c’est que les gens ne configurent plus toujours un démon de messagerie (c’est-à-dire un agent de transfert de courrier (MTA) tel que sendmail, qmail ou postfix) sur la plupart des systèmes d’exploitation de type Unix. Ainsi, les e-mails de sortie du travail cron meurent dans un dossier de spool de courrier local quelque part s’ils arrivent à ce stade. Donc, une solution pourrait être de lancer votre démon de messagerie et de vous assurer que vous avez un fichier ~ / .forward pour transférer votre courrier local vers votre "vrai" compte de messagerie.
Si vous souhaitez que vos travaux écrivent dans des fichiers journaux spécifiques, vous pouvez utiliser la redirection de sortie standard comme suggéré par @honk. Si votre travail cron est un script shell, vous pourriez avoir votre script call logger (1) ou syslog (1) ou quel que soit l’outil de ligne de commande fourni par votre système d’exploitation pour l’envoi de messages arbitraires à syslog. Vous pouvez ensuite utiliser les méthodes intégrées de votre système d’exploitation pour configurer les types de messages consignés où, peut-être en modifiant le fichier /etc/syslog.conf.
La plupart de mes tâches cron font appel aux scripts bash que j'ai écrits spécialement pour être lancés par cron pour une raison particulière. Dans ceux-ci, en particulier lorsque je les écris et les débogue initialement, 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 d'être exécutée. Notez que les scripts shell lancés à partir de cron sont considérés comme des shells non interactifs. Par conséquent, vos scripts de démarrage 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 = / chemin / vers / mon / démarrage / script" dans votre crontab avant la ligne où vous définissez le travail.
mailcommande pour lire les messages à partir de la ligne de commande. Ou regarde /var/spool/mail. Mais si vous avez installé postfix ou un logiciel de messagerie autre que sendmail standard, un autre moyen de lire les messages est nécessaire.
mail -s "cron output" test@example.comfonctionne très bien: /
less $MAILsi vous voulez voir la sortie cron pour l'utilisateur actuel ou less /var/spool/mail/rootsi vous voulez voir la sortie cron pour les commandes s'exécutant en tant que root.
Le moyen le plus simple est de capturer les erreurs d’impression et de les enregistrer dans un fichier. J'ai un cronjob qui appelle une ligne de commande php, comme ceci:
1 0 * * * php /pathOfMyApp/index.php controllerName functionName> / pathOfMyApp / log / myErrorLog 2> & 1
La partie précédant '>', c’est ma tâche principale et après '>', la capture et l’enregistrement dans un fichier situé dans un dossier de journal à la racine de mon projet, mais pouvant se trouver à la place souhaitée. Soyez vigilant: chaque fois que cronjob sera appelé, il écrasera le dernier journal. Vous pouvez utiliser '>>' pour écrire à la fin d'un fichier existant ou rechercher la commande de terminal 'cat'.
Si votre crontab utilise 'curl' ou 'wget' et fait référence à un lien, vous pouvez rechercher dans / var / log / httpd / appName pour access-log, si cron revient avec 500 ou 400, quelque chose ne va pas.
Enfin, vous pouvez aussi vérifier / var / log / messages.
Je pense que la redirection dans le fichier cron pourrait ne pas être la meilleure option dans ce cas.
Souvent, vous souhaitez que la spécification de journalisation soit co-localisée avec le script de travail cron. Dans ce cas, je suggère ce qui suit:
#!/bin/bash
exec &>> capture-log.txt
echo "Running cron-job foo at $(date)"
...
<rest of script>
Cela ajoute la sortie du travail cron au fichier capture-log.txt.
Je préfère recevoir des rapports par courrier électronique sur les tâches cron. Il suffit de mettre
MAILTO=yourmail@domain.com
dans crontab et vous recevrez un email. Bien sûr, vous devez configurer la messagerie électronique pour votre compte.