Відповіді:
Перевірте, чи мають програми, які ви запускаєте з cron, свої власні файли журналів. Якщо вони не входять, але записують свої дані на стандартні виходи, ви можете перенаправити ці файли або надіслати їх вам поштою. Всередині crontabs працює стандартне перенаправлення оболонок .
Наприклад, щоб переспрямувати вихід помилок some_job.shна some_job.errта відхилити стандартний вихід (тобто надіслати його /dev/null), додайте наступне перенаправлення у свій crontab
33 3 * * * /path/to/some_job.sh 1> /dev/null 2> /other/path/to/some_job.err
або надіслати її натомість (якщо mailє)
33 3 * * * /path/to/some_job.sh 1> /dev/null 2>&1 | mail -s "cron output" you@example.org
/dev/null?
some_job.shstdout 's до /dev/nullі тільки після його stderr до stdout (який тепер більше нічого не містить). Таким чином, тільки його stderr закінчується в stdout і передається в mail.
Більшість демонів cron на платформах, з якими я працював, автоматично надсилаю електронну пошту stdout / stderr із завдань cron користувача користувачеві, з якого це завдання походить із crontab. Я забуваю, що відбувається із загальносистемними роботами (не для користувачів, які стосуються користувачів cron з / etc / crontab). Річ у тому, що люди не завжди встановлюють демон-поштову програму (тобто агент для передачі пошти (MTA), наприклад sendmail, qmail або postfix) на більшості подібних Unix ОС. Таким чином, вихідні листи хрон просто померти в локальну папку пошти золотника де - то , якщо вони навіть отримати , що далеко. Отож, одна відповідь може полягати лише в тому, щоб запустити демона пошти, і, можливо, переконайтеся, що у вас є файл ~ / .forward для пересилання вашої локальної пошти на ваш "справжній" рахунок електронної пошти.
Якщо ви хочете, щоб ваші завдання записувались у певні файли журналів, ви можете використовувати стандартне перенаправлення виводу, як-от запропоновано @honk, або, припустивши, що ваше завдання cron є скриптом оболонки, у вас може бути ваш реєстратор викликів скриптів (1) або syslog (1) або будь-який інший інструмент командного рядка, який надає ваша ОС для надсилання довільних повідомлень у syslog. Тоді ви можете використовувати вбудовані методи вашої ОС для налаштування того, які типи повідомлень входять, де, можливо, редагуючи /etc/syslog.conf.
Більшість моїх завдань на cron посилаються на bash-скрипти, які я написав спеціально для того, щоб запустити cron з певної причини. У тих, особливо коли я їх спочатку пишу та налагоджую, я люблю використовувати bash "set -vx", щоб зробити нерозширену та розширену форму кожного рядка сценарію оболонки записати в stdout до того, як вона буде виконана. Зауважте, що сценарії оболонки, запущені з cron, вважаються не вхідними, неінтерактивними оболонками, тому ваші стандартні сценарії запуску оболонки, такі як .bashrc та .profile, не запускаються. Якщо ви використовуєте bash та хочете, щоб bash запустив сценарій запуску, вам слід визначити змінну середовища "BASH_ENV = / шлях / до / мій / запуск / скрипт" у вашій crontab перед рядком, де ви визначаєте завдання.
mailКоманду можна використовувати для читання повідомлень з командного рядка. Або подивіться /var/spool/mail. Але якщо ви встановили постфікс або іншу пошту, ніж стандартну sendmail, потрібен інший спосіб читання повідомлень.
mail -s "cron output" test@example.comпрацює просто чудово: /
less $MAILякщо ви хочете побачити вихід cron для поточного користувача або less /var/spool/mail/rootякщо ви хочете побачити вихід cron для команд, що виконуються як root.
Найпростіший спосіб - це захоплення помилок друку та збереження у файлі. У мене є cronjob, який викликає командний рядок php, наприклад:
1 0 * * * php /pathOfMyApp/index.php controllerName functionName> / pathOfMyApp / log / myErrorLog 2> & 1
Частина до '>' це мій cronjob і після '>' - це захоплення та збереження у файлі, розташованому в папці журналу в корені мого проекту, але може бути в потрібному місці. Будьте уважні: щоразу, коли буде викликано cronjob, він замінить останній журнал. Ви можете використовувати ">>" для запису в кінці наявного файлу або пошуку термінальної команди "cat".
Якщо ваш crontab використовує 'curl' або 'wget' і посилається на посилання, ви можете шукати в / var / log / httpd / appName для журналу доступу, якщо cron повертається з 500 або 400, має бути щось не так.
Нарешті, ви також можете перевірити / var / log / messages.
Я думаю, що переадресація в файлі cron може бути не найкращим варіантом у цьому випадку.
Часто ви хочете, щоб специфікація журналу знаходилася спільно зі сценарієм завдання cron. У цьому випадку я пропоную наступне:
#!/bin/bash
exec &>> capture-log.txt
echo "Running cron-job foo at $(date)"
...
<rest of script>
Це додає вихід із завдання cron до файлу capture-log.txt.
Я вважаю за краще отримувати звіти електронною поштою про роботу з Cron. Просто кажу
MAILTO=yourmail@domain.com
в crontab, і ви отримаєте електронний лист. Звичайно, ви повинні мати електронну пошту для вашого облікового запису.