Вопрос: Почему скрипты crontab не работают?


Часто, crontab сценарии не выполняются по расписанию или, как ожидалось. Для этого есть множество причин:

  1. неправильная нотация кронтаба
  2. проблема с разрешениями
  3. переменные среды

Эта вики сообщества предназначена для объединения главных причин для crontab скрипты не выполняются, как ожидалось. Напишите каждую причину в отдельном ответе.

Пожалуйста, укажите одну причину для каждого ответа - подробности о том, почему она не выполнена - и исправить (а) по этой причине.

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


446


Источник


Вы должны закрыть crontab -e для влияния cron. Например, используя vim, я редактирую файл и использую :w писать, но работа не добавляется в cron, пока я не уйду. Поэтому я не увижу работу до тех пор, пока я :q также. - DutGRIFF
Я думаю, что лучший способ отладки cron - проверить syslog и найти проблемы. - Suneel Kumar
В моем случае - письмо отправлялось в мою папку SPAM, поэтому ..... проверьте, чтобы до того, как вы потратили часы на отладку: D - almaruf
Отключение электроэнергии - Josef Klimuk


Ответы:


Разная среда

Cron передает минимальный набор переменных среды на ваши рабочие места. Чтобы увидеть разницу, добавьте фиктивную работу следующим образом:

* * * * * env> /tmp/env.output

Ждать /tmp/env.output который будет создан, затем снова удалите задание. Теперь сравните содержимое /tmp/env.output с выходом env запустите в своем обычном терминале.

Общей «добычей» здесь является PATH переменная среды различна. Возможно, ваш скрипт cron использует команду somecommand найти в /opt/someApp/bin, которые вы добавили в PATH в /etc/environment? cron игнорирует PATH из этого файла, поэтому runnning somecommand из вашего скрипта не удастся при запуске cron, но работать при запуске в терминале. Стоит отметить, что переменные из /etc/environment будет передаваться на задания cron, а не только переменные cron, которые конкретно устанавливаются, например PATH,

Чтобы обойти это, просто установите свой собственный PATH переменная в верхней части скрипта. Например.

#!/bin/bash
PATH=/opt/someApp/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

# rest of script follows

Некоторые предпочитают просто использовать абсолютные пути ко всем командам. Я рекомендую против этого. Подумайте, что произойдет, если вы хотите запустить свой скрипт в другой системе, и в этой системе команда находится в /opt/someAppv2.2/bin вместо. Вам придется пройти через весь скрипт, заменяющий /opt/someApp/bin с /opt/someAppv2.2/bin вместо того, чтобы делать небольшое редактирование в первой строке скрипта.

Вы также можете установить переменную PATH в файле crontab, которая будет применяться ко всем заданиям cron. Например.

PATH=/opt/someApp/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

15 1 * * * backupscript --incremental /home /root

428



Я думаю, что я просто упал на это, и новая линия в конце ... двойной удар. - WernerCD
+1 для env, Я полностью забыл об этой команде и думал, что ПУТЬ работает. В моем случае это было по-разному. - Izkata
@pbr Если такие каталоги остаются доступными для записи другим, система уже скомпрометирована. - geirha
@pbr sysadmin может невольно удалить корневую файловую систему. Вы не можете защищать от системных администраторов, совершающих глупые ошибки. Если вы установите более новую версию интерпретатора, которая не поддерживает обратную совместимость, я бы ожидал поломки независимо. Здравый способ справиться с этим - установить его как другую команду. Например. у вас есть версия python 2.x и установка python 3, вы устанавливаете ее как python3, а не python. А что касается / opt / someApp / bin, почему бы не использовать разумные разрешения / право собственности? любой разумный администратор обеспечит разумные разрешения / право собственности на системные файлы. - geirha
@pbr Кажется, мы можем продолжать вечно, да. Я все еще не понимаю, почему это плохая идея использовать PATH. Если вам хочется обсудить это дальше в среде, более подходящей для обсуждения, вы найдете меня в #ubuntu и #bash среди других каналов на irc.freenode.net - geirha


Моя основная информация: если вы забыли добавить новую строку в конце crontab файл. Другими словами, файл crontab должен заканчиваться пустой строкой.

Ниже приведен соответствующий раздел на страницах руководства для этой проблемы (man crontab затем пропустите до конца):

   Although cron requires that each entry in a crontab end  in  a  newline
   character,  neither the crontab command nor the cron daemon will detect
   this error. Instead, the crontab will appear to load normally. However,
   the  command  will  never  run.  The best choice is to ensure that your
   crontab has a blank line at the end.

   4th Berkeley Distribution      29 December 1993               CRONTAB(1)

284



это такой шоу-шоппер, почему он не исправлен за столь многие годы существования cron? - Capi Etheriel
Кажется, исправлено в Vixie cron: man crontab на Ubuntu 10.10 говорится, что «cron требует, чтобы каждая запись в crontab заканчивалась символом новой строки. Если в последней записи в crontab отсутствует новая строка, cron рассмотрит crontab (по крайней мере частично) и откажется его установить». (И дата в конце - 19 апреля 2010 года). - Marius Gedminas
@barraponto Это на самом деле ошибка в новых текстовых редакторах. Предполагается, что символ «новой строки» прерывание линии символ, поэтому окончательная строка в текстовом файле должна заканчиваться символом новой строки, который не отображается в редакторе. Vi и vim правильно используют персонажа, а cron был создан до того, как новые редакторы начали свое странное поведение ... Следовательно, воспроизведение его сохраняет и включает пустую строку. - Izkata
Если вы редактируете crontab, используя crontab -e он проверит синтаксис файла, прежде чем разрешить сохранение, включая проверку для новой строки. - Tom Harrison Jr
@ Chan-HoSuh, согласно man-странице «cron» требует, чтобы каждая запись в crontab заканчивалась символом новой строки. Если в последней записи в crontab отсутствует новая линия, cron рассмотрит crontab (по крайней мере частично) и откажется от установите его. " Это поведение будет вызываться при редактировании, затем сохранение crontab с использованием -e и не зависит от редактора. - Tom Harrison Jr


Демон Cron не работает. Я действительно смутился этим несколько месяцев назад.

Тип:

pgrep cron 

Если вы не видите числа, то cron не работает. sudo /etc/init.d/cron start можно использовать для запуска cron.

EDIT: вместо вызова сценариев инициализации через /etc/init.d используйте службу утилита, например.

sudo service cron start

120



Спасибо, что показал мне pgrep. Я продолжал делать ps -ef | grep foo - ripper234
Вы также можете использовать pidof cron который опускает результаты для других приложений, которые также имеют слово «cron», например, crontab. - Pithikos
Странно, все это не дает мне ничего, чтобы показать, что cron работает, но если я запустил sudo service cron start я получил start: Job is already running: cron - Colleen
service crond start если его centos / RHEL - Srihari Karanth


Имена файлов сценариев в cron.d/, cron.daily/, cron.hourly/и т. д., не должны содержать точку (.), в противном случае пробежки будут пропущены.

См. Разделы (8):

   If neither the --lsbsysinit option nor the --regex option is given then
   the names must consist entirely of upper and lower case  letters,  dig‐
   its, underscores, and hyphens.

   If  the  --lsbsysinit  option  is given, then the names must not end in
   .dpkg-old  or .dpkg-dist or .dpkg-new or .dpkg-tmp, and must belong  to
   one  or more of the following namespaces: the LANANA-assigned namespace
   (^[a-z0-9]+$);   the   LSB   hierarchical   and   reserved   namespaces
   (^_?([a-z0-9_.]+-)+[a-z0-9]+$);  and  the  Debian cron script namespace
   (^[a-zA-Z0-9_-]+$).

Итак, если у вас есть скрипт cron backup.sh, analyze-logs.pl в cron.daily/ вам лучше удалить имена расширений.


81



Это особенность, а не ошибка - она ​​хранит такие вещи, как myscript.backup или myscript.original или myscript.rpm-new, которые запускаются рядом с myscript. - pbr
@pbr: имеет смысл. По крайней мере, это было бы полезно для отладки, если run-parts --test (или другой мнимый вариант, например --debug будет выводить файлы, которые он пропускает, включая причину. - Rabarberski
Если это особенность, это не очень приятно :( Многие люди используют точку в имени файла (наиболее распространенным является backup.sh). Если вы хотите, чтобы скрипт прекратил выполнение, самым логичным методом будет удалите его из каталога cron.d. - MatuDuke
Это такая плохая функция, что это ошибка. Обычно принято требовать определенного окончания (например, «.list» или «.cron» или что-то еще), если люди хотят убедиться, что вещи только запускаются, когда они предназначены. Произвольный выбор точки в качестве вероятного разделителя для «.bak» или «.temp» или что-то еще совершенно непредсказуем, за исключением того, что он будет предсказуемо путать людей. Законные окончания, такие как «.sh» и «.pl», широко используются десятилетиями. Однако многие люди используют «_bak» или «_temp» или «-bak» вместо точки. Это ужасный выбор дизайна; это лучшая проектная ошибка. - Teekin


Во многих средах cron выполняет команды, используя sh, в то время как многие полагают, что он будет использовать bash,

Предложения по проверке или исправлению этого для команды сбоя:

  • Попробуйте запустить команду в sh посмотреть, работает ли он
  • Оберните команду в bash subshell, чтобы убедиться, что она запущена в bash:
    bash -c "mybashcommand"
  • Скажите cron, чтобы запустить все команды в bash, установив оболочку в верхней части вашего crontab:
    SHELL=/bin/bash
  • Если команда является скриптом, убедитесь, что скрипт содержит shebang:
    #!/bin/bash

55



Предложение bash очень полезно, исправлена ​​проблема с моим cron. - Maxim Galushka
Это просто вызвало у меня 1 час поиска / устранения неполадок. Еще более смущающе, если вы не знаете о проблеме, скрипт будет запускаться вручную просто отлично, если вы типичная оболочка bash, но не с cron, Благодаря! - Hendy
Давно я столкнулся с чем-то связанным: команда source находится в bash, но не sh. В cron / sh используйте период: . envfile скорее, чем source envfile, - kungphu


У меня были некоторые проблемы с часовыми поясами. Cron работал со свежим временем установки. Решением было перезапустить cron:

sudo service cron restart

34



Да, после изменения часового пояса в системе необходимо либо перезапустить все службы, которые интересуются временем, либо перезагрузкой. Я предпочитаю перезагрузку, чтобы убедиться, что все поймал. - pbr
О Боже, убил часов на этом. Пробный перезапуск службы после * * * * * touch /tmp/cronworksничего не делал, но есть RELOAD в cronlog. - НЛО


Если ваша команда crontab имеет % символ в нем, cron пытается интерпретировать его. Поэтому, если вы использовали какую-либо команду с % в нем (например, в спецификации формата для команды date) вам нужно будет избежать этого.

Это и другие хорошие подробности:
http://www.pantz.org/software/cron/croninfo.html


29



Это то, что заставило мою работу на Крон провалиться на прошлой неделе. Наконец выяснилось, что моя дата не имела escape-символа (обратная косая черта для любых других людей, которые ищут, каков символ побега). Ура! - Valien
Смотрите также Как я могу выполнить date внутри задания вкладки cron? - Jared Beck
Это тоже немного меня. Благодаря! - stefansundin