Как войти в работу cron?

Question

Я хочу знать, как я могу точно видеть, что задания cron делают при каждом выполнении. Где находятся файлы журналов? Или я могу отправить вывод на мою электронную почту? Я установил адрес электронной почты для отправки журнала при выполнении задания cron, но пока ничего не получил.

Answer 1

* * * * * myjob.sh >> /var/log/myjob.log 2>&1

зарегистрирует весь вывод задания cron в /var/log/myjob.log

. Вы можете использовать mail для отправки электронных писем.Большинство систем отправит необработанный вывод cron задания по электронной почте пользователю root или соответствующему пользователю.

Answer 2

По умолчанию cron регистрирует в / var / log / syslog, чтобы вы могли видеть записи, связанные с cron, используя:

grep CRON /var/log/syslog

https://askubuntu.com/questions/56683/where-is-the-cron-crontab-log

Answer 3

Существует как минимум три различных типа регистрации:

1. Регистрация перед выполнением программы, которая регистрирует только если cronjob TRIED для выполнения команды. Этот находится в / var / log / syslog, как уже упоминалось @Matthew Lock.

2. Ведение журнала ошибок ПОСЛЕ попытки выполнения программы, которые можно отправить электронное письмо или файл, как упомянуто @Spliffster. Я предпочитаю войти в файл, потому что с электронной почтой, то у вас есть новый источник проблемы, и его проверка, если отправка и прием электронной почты работает в совершенстве. Иногда это так, иногда нет. Например, в простой обычный настольный компьютер, в котором вы не заинтересованы настраивая smtp, иногда вы предпочитаете входить в файл:

    * * * *  COMMAND_ABSOLUTE_PATH > /ABSOLUTE_PATH_TO_LOG 2>&1
   

   • Я бы также рассмотрел проверку прав доступа / ABSOLUTE_PATH_TO_LOG и запустил команду из прав этого пользователя. Только для проверки, пока вы проверяете, может ли это быть потенциальным источником проблем.
3. Ведение журнала самой программы с собственной обработкой ошибок и ведением журнала для целей отслеживания.

Существует несколько распространенных источников проблем с cronjobs: * АБСОЛЮТНЫЙ ПУТЬ двоичного файла, который будет выполнен. Когда вы запускаете его с вашего shell, это может работать, но процесс cron, похоже, использует другой среда, и, следовательно, он не всегда находит двоичные файлы, если вы не использовать абсолютный путь. * БИБЛИОТЕКИ, используемые двоичным файлом. Это более или менее аналогично предыдущему пункту, но убедитесь, что, если просто указать имя команды, то оно относится именно к двоичному файлу, который использует ту же библиотеку, или, что лучше, проверить, что двоичный файл, на который вы ссылаетесь, использует абсолютный путь это то же самое, что вы имеете в виду, когда вы используете консоль напрямую. Двоичные файлы можно найти с помощью команды locate, например:

$locate python

Убедитесь, что двоичный файл, на который вы будете ссылаться, является тем же самым двоичным файлом, который вы вызываете в своей оболочке, или просто протестируйте снова в своей оболочке, используя абсолютный путь, который вы планируете указать в cronjob.

• Другим распространенным источником проблем является синтаксис cronjob. Помните, что есть специальные символы, которые можно использовать для списков (запятых), для определения диапазонов (тире -), для определения приращения диапазонов (косых черт) и т. Д. Посмотрите: http://www.softpanorama.org/Utilities/cron.shtml

Answer 4

Вот мой код:

* * * * * your_script_fullpath >> your_log_path 2>&1

Answer 5

В Ubuntu вы можете включить файл cron.log, содержащий только записи CRON.

Раскомментируйте строку, в которой упоминается cron в /etc/rsyslog.d/50-default.conf файле:

#  Default rules for rsyslog.
#

#                       For more information see rsyslog.conf(5) and /etc/rsyslog.conf

#
# First some standard log files.  Log by facility.
#
auth,authpriv.*                 /var/log/auth.log
*.*;auth,authpriv.none          -/var/log/syslog
#cron.*                          /var/log/cron.log

Сохраните и закройте файл, а затем перезапустите службу rsyslog:

sudo systemctl restart rsyslog

Теперь вы можете видеть записи журнала cron в своем собственном файле:

sudo tail -f /var/log/cron.log

Пример выходных данных:

Jul 18 07:05:01 machine-host-name CRON[13638]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)

Однако вы не увидите больше информации о том, какие сценарии фактически выполнялись внутри /etc/cron.daily или /etc/cron.hourly, если только эти сценарии не перенаправят вывод в cron.log (или, возможно, в какой-либо другой файл журнала).

Если вы хотите проверить, работает ли crontab и не нужно искать его в cron.log или syslog, создайте crontab, который перенаправляет вывод в файл журнала по вашему выбору - что-то вроде:

# For more information see the manual pages of crontab(5) and cron(8)
#
# m h  dom mon dow   command
30 2 * * 1 /usr/local/sbin/certbot-auto renew >> /var/log/le-renew.log 2>&1

Шаги взяты из: https://www.cyberciti.biz/faq/howto-create-cron-log-file-to-log-crontab-logs-in-ubuntu-linux/

Answer 6

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

Вы можете использовать MAILTO=recipient в файле crontab для отправки сообщений электронной почты на другую учетную запись.

Чтобы это работало, вам нужно, чтобы почта работала правильно. Доставка в локальный почтовый ящик обычно не является проблемой (на самом деле, шансы ls -l "$MAIL" покажут, что вы уже получили некоторые), но для того, чтобы получить его из коробки и выйти в Интернет, требуется MTA (Postfix, Sendmail, что вам) быть правильно настроенным для подключения к миру.

Если выходных данных нет, электронное письмо не будет создано.

Распространенным условием является перенаправление вывода в файл, и в этом случае, конечно, демон cron не увидит, что задание вернет какой-либо вывод. Один из вариантов - перенаправить стандартный вывод в файл (или написать сценарий, чтобы он никогда ничего не печатал - возможно, он вместо этого сохраняет результаты в базе данных или выполняет задачи обслуживания, которые просто ничего не выводят?) И получает электронное письмо только при наличии сообщение об ошибке.

Для перенаправления обоих выходных потоков используется синтаксис

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

Обратите внимание, как мы добавляем (удваиваем >>) вместо перезаписи, так что выходные данные любого предыдущего задания не заменяются выходными данными следующего.

Как предлагается во многих ответах, вы можете отправить оба выходных потока в один файл; замените второе перенаправление на 2>&1, чтобы сказать «стандартная ошибка должна идти везде, где идет стандартный вывод». (Но я не особо одобряю эту практику. Это в основном имеет смысл, если вы действительно ничего не ожидаете от стандартного вывода, но, возможно, что-то упустили, возможно, из внешнего инструмента, который вызывается из вашего скрипта.)

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

Обычный антипаттерн - это перенаправить все на /dev/null (а затем попросить переполнение стека, чтобы помочь вам выяснить, что пошло не так, когда что-то не работает; но мы также не можем увидеть потерянный вывод!)

Внутри вашего скрипта убедитесь, что регулярный вывод (фактические результаты, в идеале в машиночитаемой форме) и диагностика (обычно отформатированные для читателя-человека) разделены. В сценарии оболочки

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

Некоторые платформы (например, GNU Awk) позволяют вам использовать имя файла /dev/stderr для сообщений об ошибках, но это не всегда переносимо; в Perl warn и die печатают со стандартной ошибкой; в Python напишите sys.stderr или используйте logging; в Ruby попробуйте $stderr.puts. Обратите также внимание на то, как сообщения об ошибках должны включать имя сценария, который выдал диагностическое сообщение.

Answer 7

Если вы запускаете какую-то команду с помощью sudo, она этого не допустит. Судо нуждается в tty.

Answer 8

Если вы все еще хотите проверить работу cron, вы должны предоставить действительный учетная запись электронной почты при настройке заданий Cron в cPanel.

Когда вы укажете действительный адрес электронной почты, вы получите вывод выполненного задания cron. Таким образом, вы сможете проверить это и убедиться, что все было выполнено правильно. Обратите внимание, что вы не получите электронное письмо, если нет результатов команды cron job.

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