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

Ответ 1

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

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

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

Ответ 2

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

grep CRON /var/log/syslog

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

Ответ 3

Вот мой код:

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

Ответ 4

Существует не менее трех различных типов ведения журнала:

• Ведение журнала ПЕРЕД выполнением программы, которая только регистрирует, ЕСЛИ cronjob TRIED для выполнения команды. Этот находится в /var/log/syslog, как уже упоминалось @Matthew Lock.

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

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

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

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

$locate python

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

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

Ответ 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/

Ответ 6

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

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

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

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

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

Чтобы перенаправить оба выходных потока, синтаксис

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

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

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

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

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

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

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

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

Ответ 7

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

Ответ 8

Все вышеперечисленное не работает для меня. Итак, я должен добавить "MAILTO = [мой адрес электронной почты]" в верхней части файла crontab в /etc/cron.d/, и я получил ответ, потому что моя команда cron получила ошибки.

Ответ 9

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

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

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