Де записуються помилки cron?

Якщо я налаштував cronзавдання неправильно, вони, здається, мовчки виходять з ладу. Де слід шукати журнал помилок, щоб зрозуміти, що пішло не так?

Як зазначали інші, cronнадішлемо вам електронну пошту з будь-якої програми, яку вона запускає (якщо є вихід). Отже, якщо ви не отримаєте жодного результату, в основному є три можливості:

1. crond не міг навіть запустити оболонку для запуску програми або надсилання електронної пошти
2. crond виникли проблеми з відправленням виводу, або пошта була загублена.
3. програма не дала жодного результату (включаючи повідомлення про помилки)

Випадок 1. дуже малоймовірний, але щось треба було записати в журналах cron. Cron має власну зарезервовану систему syslog, тому вам слід заглянути /etc/syslog.conf(або еквівалентний файл у вашому дистрибутиві), щоб побачити, куди надсилаються повідомлення об'єкта cron. Популярні напрямки включають /var/log/cron: /var/log/messagesта /var/log/syslog.

У другому випадку слід ознайомитись з журналами демон демонів: повідомлення з демона Cron зазвичай з'являються як з root@yourhost. Ви можете використовувати MAILTO=...рядок у файлі crontab, щоб переслати електронною поштою електронну пошту на певну адресу, що полегшить отримання файлів журналів демонів mailer. Наприклад:

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

У випадку 3 ви можете перевірити, чи дійсно програма запускалася, додавши іншу команду, ефект якої ви можете легко перевірити: наприклад,

00 15 * * * /a/command; touch /tmp/a_command_has_run

тож ви можете перевірити, чи crondсправді щось запущено, подивившись на mtime /tmp/a_command_has_run.

Ви завжди можете явно надіслати висновок завдання в файл журналу:

0 8 * * * /usr/local/bin/myjob > /var/log/myjob.log 2>&1

Майте на увазі, що це буде витісняти згадану раніше поведінку пошти, оскільки crond iself не отримає жодного результату із завдання. Якщо ви хочете зберегти таку поведінку, вам слід заглянути в трійник (1).

Якщо ви не бачите електронної пошти, ви можете спам корінь @ yourcompany з помилками, які можуть дуже дратувати людей, які використовують цей обліковий запис для моніторингу. Спробуйте надіслати висновок замість Syslog:

*/5 * * * * yourcronjob 2>&1 | /usr/bin/logger -t yourtag

Потім зачекайте запуску cronjob і шукайте помилку в / var / log / messages (або /var/log/user.log у деяких системах).

Це чудово підходить для повідомлень про помилки, довжиною яких є лише 1-2 рядки, наприклад "yourcronjob: команда не знайдена". Він також використовує існуючу інфраструктуру системного журналу (Logrotation, центральний syslogging, Splunk тощо). Це також зменшує спам електронної пошти до root.

Це може бути не гарним рішенням, якщо ваша робота виконує сотні ліній виводу.

Конфігурація Cron за замовчуванням надішле вам пошту з результатами вашої програми. Якщо це не вдасться, ви можете спробувати обернути свою програму, що відмовляється, у скрипт оболонки, що гарантує, що програма не виходить з ладу, і ви можете додатково записати результат.

Це налаштування, яке можна налаштувати в деяких реалізаціях cron.

Ви повинні отримувати електронну пошту, crondколи завдання або не виконується, або коли завдання повертає ненульовий код виходу. Спробуйте ввести:

$ mailx

в командному рядку.

mailx(1)є основною програмою читання пошти у більшості кожної системи Unixlike. Це дуже примітивно за сучасними мірками, але ви можете майже розраховувати, що він завжди буде доступний. Можливо, доступні й інші, більш якісні поштові агенти, але їх достатньо, щоб ви ніколи не знали, який з них встановлений на якійсь випадковій машині, якою ви користуєтесь.

Зауважте, що якщо ви не налаштували свою систему як Інтернет-сервер електронної пошти, ця поштова підсистема використовується лише в межах машини. Ви можете надсилати електронну пошту та отримувати від інших користувачів на машині, але ви, можливо, не зможете надсилати електронну пошту у світ, і електронна пошта з навколишнього світу, безумовно, не зможе зайти на вашу машину.

Cron записує основну інформацію до /var/log/messages, але надсилає будь-яку програму виводу користувачеві, що викликає.

Я наткнувся на цю нитку кілька років тому, відчуваючи ті самі проблеми, і зовсім недавно натрапив на рішення вищезгаданих випадків Рікардо. Відсутність електронної пошти важко виявити (як ви згадали), і ви, звичайно, не хочете спамувати свій root @ електронну пошту вашої компанії. Якщо ви зацікавлені, перегляньте deadmanssnitch.com. . Цей інструмент, здається, вирішує вищезазначені випадки. У використанні це здається досить простим - просто додайте біт коду, який інструмент надає вашій роботі. Якщо ваша робота не працює у вказаному внутрішньому, вам надійде сповіщення. Якщо робота знову почне працювати, ви також отримаєте сповіщення.

Я використовую vixie-cron, тому не знаю, чи це стосується всього. Але у мене є dead.letterфайл, який містить усі результати роботи.

У своїй /root/папці, crons.cronяку я встановив як свій crontab, запустивши crontab /root/crons.cron. dead.letterбуде створено /root/також.

Редагувати Я просто Google'd dead.letter, і це лист, який не можна доставити. Це, мабуть, не має нічого спільного з кроном. Якщо у вас неправильно налаштована пошта (як у мене), ви отримаєте файл.

Для новачків це може бути біль налагодження. Обов’язково не обмінюйтесь значеннями хвилини та години. Спочатку настає хвилина, потім година. Якщо ви подаєте значення менше 12 для кожного, він прийме їх, але може не працювати як очікувалося, ні зовсім.