Где посмотреть ошибки cron

As others have pointed out, cron will email you the output of any program it runs (if there is any output). So, if you don’t get any output, there are basically three possibilities:

1. crond could not even start a shell for running the program or sending email
2. crond had troubles mailing the output, or the mail was lost.
3. the program did not produce any output (including error messages)

Case 1. is very unlikely, but something should have been written in the cron logs. Cron has an own reserved syslog facility, so you should have a look into /etc/syslog.conf (or the equivalent file in your distro) to see where messages of facility cron are sent. Popular destinations include /var/log/cron, /var/log/messages and /var/log/syslog.

In case 2., you should inspect the mailer daemon logs: messages from the Cron daemon usually appear as from root@yourhost. You can use a MAILTO=... line in the crontab file to have cron send email to a specific address, which should make it easier to grep the mailer daemon logs. For instance:

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

In case 3., you can test if the program was actually run by appending another command whose effect you can easily check: for instance,

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

so you can check if crond has actually run something by looking at
the mtime of /tmp/a_command_has_run.

As others have pointed out, cron will email you the output of any program it runs (if there is any output). So, if you don’t get any output, there are basically three possibilities:

1. crond could not even start a shell for running the program or sending email
2. crond had troubles mailing the output, or the mail was lost.
3. the program did not produce any output (including error messages)

Case 1. is very unlikely, but something should have been written in the cron logs. Cron has an own reserved syslog facility, so you should have a look into /etc/syslog.conf (or the equivalent file in your distro) to see where messages of facility cron are sent. Popular destinations include /var/log/cron, /var/log/messages and /var/log/syslog.

In case 2., you should inspect the mailer daemon logs: messages from the Cron daemon usually appear as from root@yourhost. You can use a MAILTO=... line in the crontab file to have cron send email to a specific address, which should make it easier to grep the mailer daemon logs. For instance:

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

In case 3., you can test if the program was actually run by appending another command whose effect you can easily check: for instance,

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

so you can check if crond has actually run something by looking at
the mtime of /tmp/a_command_has_run.

Ответы:

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

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

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

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

$ mailx

Где хранится информация о запуске заданий по расписанию? Для проверки используем Ubuntu Linux 12.04/14.04 LTS сервер. Как проверит, запущен ли cron и правильно ли он работает?

Как проверить запущен ли cron (планировщик заданий)? Используйте команду pgrep  или ps

Результат

Так же вы можете проверить файл /var/log/syslog используя команду grep что бы получить информации о работе планировщика cron

Результат:

Где хранятся журналы работы cron на Ubuntu Linux?

Журналы хранятся в файле /var/log/cron.log. Вы можете настроить его следующим образом. Редактировать /etc/rsyslog.d/50-default.conf файл с помощью текстового редактора, например, vi или nano:

или

Найдите строку

Необходимо её раскомментировать, и перезапустить оба сервиса:

Теперь все сообщения об ошибках в работе планировщика можно будет просматривать в файле

Воспользуйтесь различными командами для поиска нужной информации в логе

 Предоставляем уcлуги администрирования серверов Linux Ububtu

Нет похожих статей.

Как пользователь Linux, вы, вероятно, уже знакомы с crontab.

Вы можете автоматизировать задачи, запуская команды и скрипты по заданному расписанию.

Хотите автоматически создавать резервные копии?

Crontab – вам в этом поможет.

Здесь я не буду углубляться в использование crontab.

Я сосредоточусь на том, чтобы показать вам различные способы проверки логов crontab.

Это поможет выяснить, выполнились ли ваши cronjobs по расписанию или нет.

Метод 1: Проверим syslog на наличие записей crontab

Согласно иерархии каталогов Linux, в каталоге /var/log в Linux хранятся логи системы, служб и запущенных приложений.

Хотя журналы cron также находятся в этом каталоге, стандартного файла для этих журналов не существует. Разные дистрибутивы хранят их в разных файлах.

🐧 Руководство для начинающих по системным логам в системах Linux

В дистрибутивах на базе Debian файл /var/log/syslog содержит логи выполнения заданий cron, и к нему следует обращаться в случае, если задания cron не работают:

cat /var/log/syslog | grep -w 'cron'

После выполнения вышеуказанной команды вы увидите в терминале список всех заданий cron.

Команда grep отфильтрует сообщения, связанные с cron, от остальных.

Для дистрибутивов на базе RedHat логи cron находятся в специальном файле /var/log/cron.

В обоих случаях для доступа к журналам вам, вероятно, потребуется указать ключевое слово sudo или использовать учетную запись root.

Метод 2: Использование пользовательского файла логов (рекомендуется)

Рекомендуется использовать отдельный пользовательский файл для регистрации заданий cron.

Для этого вы можете настроить ‘rsyslog’ для пересылки журналов cron.

Rsyslog – это служба Linux, которая имеет функции, аналогичные протоколированию Syslog.

Просто создайте файл cron.log в каталоге /etc/rsyslog.d:

touch /var/log/cron.log

Теперь откройте для редактирования файл /etc/rsyslog.d/50-default.conf:

nano /etc/rsyslog.d/50-default.conf 

и найдите строку, начинающуюся с #cron.* и удалите # в начале строки.

Чтобы изменения заработали, сохраните и закройте этот файл и, наконец, перезапустите службу rsyslog и проверьте ее состояние:

sudo systemctl restart rsyslog

sudo systemctl status rsyslog

Статус службы должен быть выделен как active (running).

Метод 3: Использование специальных служб, такиъ как Cronitor, для мониторинга заданий cron

Cronitor – это служба, которую можно развернуть для мониторинга любого типа заданий cron.

Многие версии cron начинают вести журнал при выполнении запланированного задания или при возникновении проблем с crontab.

Однако, выход из задания cron или статус его завершения не регистрируется.

Здесь на помощь приходит Cronitor, который работает идеально.

Это комплексное решение для всех ваших потребностей в crontab.

🐧 Обзор средств мониторинга и управления логами с открытым исходным кодом для Linux

Он собирает логи, метрики и статус всех заданий и создает мгновенные предупреждения о сбое или неудачном запуске задания.

Все это можно увидеть через веб-интерфейс.

Для Cronitor или CronitorCLI, установленных на Kubernetes, журналы могут быть записаны в объеме до 100 МБ за одно выполнение.

Другие инструменты и сервисы мониторинга, такие как Better Uptime, также предоставляют возможность автоматического мониторинга заданий cron.

🐧 Как использовать journalctl для анализа логов на Linux

Заключение

Системные журналы очень важны для поиска и диагностики проблем, связанных с системой, и журналы cron не являются исключением.

Syslog хранит журналы, связанные с crontab, однако рекомендуется иметь специальный файл журнала для cron.

Также поможет веб-сервис, например, Cronitor, Better Uptime или Uptime Robot.

см. также:

• 🐧 Как запустить несколько команд в одном задании Cron
• 🐍 Планирование выполнения скриптов Python с помощью Crontab
• ⏲️ Запуск задания cron каждые 12 часов (дважды в день)
• 🐧 Запуск Cron каждые 30 секунд
• ⏲️ Как просмотреть или составить список заданий Cron на Linux
• ☸️ Как создать job Kubernetes из работы cron job
• 😿 Как перечислить задания Cron в Linux

cron already sends the standard output and standard error of every job it runs by mail to the owner of the cron job.

You can use MAILTO=recipient in the crontab file to have the emails sent to a different account.

For this to work, you need to have mail working properly. Delivering to a local mailbox is usually not a problem (in fact, chances are ls -l "$MAIL" will reveal that you have already been receiving some) but getting it off the box and out onto the internet requires the MTA (Postfix, Sendmail, what have you) to be properly configured to connect to the world.

If there is no output, no email will be generated.

A common arrangement is to redirect output to a file, in which case of course the cron daemon won’t see the job return any output. A variant is to redirect standard output to a file (or write the script so it never prints anything — perhaps it stores results in a database instead, or performs maintenance tasks which simply don’t output anything?) and only receive an email if there is an error message.

To redirect both output streams, the syntax is

42 17 * * * script >>stdout.log 2>>stderr.log

Notice how we append (double >>) instead of overwrite, so that any previous job’s output is not replaced by the next one’s.

As suggested in many answers here, you can have both output streams be sent to a single file; replace the second redirection with 2>&1 to say «standard error should go wherever standard output is going». (But I don’t particularly endorse this practice. It mainly makes sense if you don’t really expect anything on standard output, but may have overlooked something, perhaps coming from an external tool which is called from your script.)

cron jobs run in your home directory, so any relative file names should be relative to that. If you want to write outside of your home directory, you obviously need to separately make sure you have write access to that destination file.

A common antipattern is to redirect everything to /dev/null (and then ask Stack Overflow to help you figure out what went wrong when something is not working; but we can’t see the lost output, either!)

From within your script, make sure to keep regular output (actual results, ideally in machine-readable form) and diagnostics (usually formatted for a human reader) separate. In a shell script,

echo "$results"  # regular results go to stdout
echo "$0: something went wrong" >&2

Some platforms (and e.g. GNU Awk) allow you to use the file name /dev/stderr for error messages, but this is not properly portable; in Perl, warn and die print to standard error; in Python, write to sys.stderr, or use logging; in Ruby, try $stderr.puts. Notice also how error messages should include the name of the script which produced the diagnostic message.

You can create a cron.log file to contain just the CRON entries that show up in syslog. Note that CRON jobs will still show up in syslog if you follow the following directions.

Open the file

/etc/rsyslog.d/50-default.conf

Find the line that starts with:

#cron.*

uncomment that line, save the file, and restart rsyslog:

sudo service rsyslog restart

You should now see a cron log file here:

/var/log/cron.log

Cron activity will now be logged to this file (in addition to syslog).

Note that in cron.log you will see entries for when cron ran scripts in /etc/cron.hourly, cron.daily, etc. — e.g. something like:

Apr 12 14:17:01 cd CRON[14368]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)

However, you will not see more information about what scripts were actually ran inside /etc/cron.daily or /etc/cron.hourly, unless those scripts direct output to the cron.log (or perhaps to some other log file).

If you want to verify if a crontab is running and not have to search for it in cron.log or syslog, create a crontab that redirects output to a log file of your choice — something like:

01 14 * * * /home/joe/myscript >> /home/log/myscript.log 2>&1

This will redirect all standard output and errors that may be produced by the script that is run to the log file specified.

В среде Linux чаще всего используется слово «cron jobs». Для тех, кто не знает об этом. Задание cron — это планировщик задач, который автоматизирует все повторяющиеся задачи в дистрибутиве Linux. Задания Cron выполняются в указанную дату и время, которые планируются системным администратором. Таким образом, журналы или история заданий cron хранятся в файле журнала, который помогает системному администратору проверить, выполняются ли задания cron в указанное время или нет.

В этой статье мы обсудим, как пользователь может просматривать файлы журналов cron в среде Linux. Мы выполнили все задачи в системе Ubuntu 20.04, которые помогут вам лучше понять журналы cron.

Откройте терминал, нажав сочетание клавиш Ctrl + Alt + t. Теперь, используя следующие два разных метода, можно легко получить доступ к событиям журнала cron:

Метод 1: проверьте события журналов cron через системный журнал

Это очень простой и легкий способ проверить, выполняются ли в вашей системе события журнала cron. Войдите в систему как пользователь root на терминале и введите следующую команду:

# cat /var/log/syslog | grep cron

Следующие события журналов cron должны отображаться на терминале:

Метод 2: мониторинг журналов cron путем настройки файла cron.log

Рекомендуемый способ — создать отдельный файл cron.log для отслеживания или проверки событий журналов cron в вашей системе Linux. Для этого откройте файл /etc/rsyslog.d/50-default.conf, выполнив следующую команду:

$ sudo nano /etc/rsyslog.d/50-default.conf

Найдите в этом файле ’# cron. * /Var/log/cron.log’ и раскомментируйте эту строку, которая также показана на следующем снимке экрана:

Теперь создайте cron.log с помощью любого исходного кода или текстового редактора.

$ sudo nano /var/log/cron.log

Перезапустите службу rsyslog, а затем проверьте состояние работы этой службы в вашей системе с помощью следующей команды:

$ sudo systemctl restart rsyslog

$ sudo systemctl status rsyslog

В окне терминала должен быть напечатан следующий вывод:

Теперь все события журнала cron должны сохраняться в файле cron.log.

Для просмотра в реальном времени cron регистрирует события с помощью команды watchcron. Итак, создайте файл watchcron следующим образом:

Добавьте в этот файл следующие строки:

#!/bin/bash

watch -n 10 tail -n 25 /var/log/cron.log

Сохраните этот файл в nano, используя Ctrl + o, а затем нажмите Ctrl + x, чтобы выйти из этой среды.

Здесь указанный сторожевой кронштейн обновляет страницу журналов событий через 10 секунд и отображает последние 25 событий на странице.

Установите разрешения для исполняемого файла для этого файла с помощью следующей команды:

$ sudo chmod +x watchcron

Скопируйте этот файл в папку ’/ usr / sbin’ следующим образом:

$ sudo cp watchcron /usr/sbin

Теперь, чтобы проверить события журналов cron в реальном времени, выполните на терминале следующую команду:

На терминале появится следующее окно:

Заключение

В этой статье мы объяснили, как вы можете проверять или отслеживать события журналов cron в режиме реального времени с помощью одной команды watchcron.