Почему не работает крона

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

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

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

Вики-сообщество призвано объединить основные причины crontab сценарии не выполняются, как ожидалось. Запишите каждую причину в отдельном ответе.

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

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

46 ответов

Другая среда

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

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

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

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

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

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

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

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

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

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

РЕДАКТИРОВАТЬ: Вместо того, чтобы вызывать сценарии инициализации через /etc/init.d, используйте служебную утилиту, например

Имя файла скрипта в cron.d/ , cron.daily/ , cron.hourly/ и т. д., не должны содержать точку ( . ), иначе run-parts пропустит их.

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

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

Предложения для проверки или исправления ошибки команды:

Попробуйте запустить команду в sh чтобы увидеть, работает ли это:

Оберните команду в подоболочку bash, чтобы убедиться, что она запускается в bash:

Скажите cron запустить все команды в bash, установив оболочку в верхней части вашего crontab:

Если команда является скриптом, убедитесь, что скрипт содержит шебанг:

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

Абсолютный путь должен использоваться для скриптов:

Например, /bin/grep следует использовать вместо grep :

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

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

Cron вызывает скрипт, который не является исполняемым.

Запустив chmod +x /path/to/scrip скрипт становится исполняемым и должен решить эту проблему.

Также возможно, что срок действия пароля пользователя истек. Даже пароль root может истечь. Вы можете tail -f /var/log/cron.log и вы увидите сбой cron с истекшим сроком действия пароля. Вы можете установить пароль, чтобы никогда не истек, делая это: passwd -x -1

В некоторых системах (Debian, Ubuntu) ведение журнала для cron не включено по умолчанию. В /etc/rsyslog.conf или /etc/rsyslog.d/50-default.conf строка:

следует отредактировать ( sudo nano /etc/rsyslog.conf ) оставлено без комментариев:

После этого вам нужно перезапустить rsyslog через

В некоторых системах (Ubuntu) отдельный файл регистрации для cron не включен по умолчанию, но связанные с cron журналы появляются в файле syslog. Можно использовать

для просмотра сообщений, связанных с cron.

Если ваш cronjob вызывает GUI-приложения, вы должны сообщить им, какой DISPLAY они должны использовать.

Пример: запуск Firefox с помощью cron.

Ваш скрипт должен содержать export DISPLAY=:0 где-то.

Боюсь, проблемы с разрешениями встречаются довольно часто.

Обратите внимание, что распространенным обходным решением является выполнение всего, используя crontab root, который иногда является действительно плохой идеей. Установка правильных разрешений — определенно упущенная проблема.

Небезопасное разрешение таблицы cron

Таблица cron отклоняется, если ее разрешение небезопасно

Проблема решена с

Сценарий зависит от местоположения. Это связано с тем, что в скрипте всегда используются абсолютные пути, но это не совсем одно и то же. Ваша работа cron может потребоваться cd перед запуском в конкретный каталог, например, задача rake в приложении Rails может потребоваться в корне приложения для Rake, чтобы найти правильную задачу, не говоря уже о соответствующей конфигурации базы данных и т. д.

Итак, запись в crontab

23 3 * * * /usr/bin/rake db:session_purge RAILS_ENV=production

будет лучше как

Или, чтобы сделать запись в crontab более простой и менее хрупкой:

23 3 * * * /home/ /scripts/session-purge.sh

со следующим кодом в /home/ /scripts/session-purge.sh :

Спецификации Crontab, которые работали в прошлом, могут сломаться при перемещении из одного файла crontab в другой. Иногда причина в том, что вы переместили спецификацию из системного файла crontab в пользовательский файл crontab или наоборот.

Формат спецификации задания cron отличается в файлах crontab пользователей (/var/spool/cron/username или /var/spool/cron/crontabs/username) и системных crontabs ( /etc/crontab и файлы в /etc/cron.d ).

Системные crontabs имеют дополнительное поле ‘user’ прямо перед командой для запуска.

Это приведет к ошибкам с указанием таких вещей, как george; command not found когда вы перемещаете команду из /etc/crontab или файл в /etc/cron.d в файл crontab пользователя.

И наоборот, cron будет выдавать такие ошибки, как /usr/bin/restartxyz is not a valid username или подобное, когда происходит обратное.

Сценарий cron вызывает команду с параметром —verbose

У меня произошел сбой скрипта cron, потому что я набирал скрипт на автопилоте и включил опцию —verbose:

Сценарий выполнялся нормально при выполнении из оболочки, но не работал при запуске из crontab, поскольку подробный вывод выводится на стандартный вывод при запуске из оболочки, но нигде при запуске из crontab. Легко исправить, чтобы удалить «V»:

Самая частая причина, по которой я видел сбой cron в неверно указанном расписании. Требуется практика, чтобы указать работу, запланированную на 23:15 как 30 23 * * * вместо * * 11 15 * или же 11 15 * * * , День недели для рабочих мест после полуночи также сбивается с толку 2-6 после полуночи нет 1-5 , Конкретные даты обычно являются проблемой, так как мы редко их используем * * 3 1 * не 3 марта.

Если вы работаете с различными платформами, используя неподдерживаемые параметры, такие как 2/3 во времени спецификации также могут вызвать сбои. Это очень полезная опция, но она не всегда доступна. Я также сталкивался с проблемами, такие как списки 1-5 или же 1,3,5 ,

Использование неквалифицированных путей также вызвало проблемы. Путь по умолчанию обычно /bin:/usr/bin поэтому будут выполняться только стандартные команды. Эти каталоги обычно не имеют желаемой команды. Это также влияет на сценарии, использующие нестандартные команды. Другие переменные среды также могут отсутствовать.

Полное уничтожение существующего crontab вызвало у меня проблемы. Я сейчас загружаю из файла копию. Это можно восстановить из существующего crontab, используя crontab -l если это будет забито Я храню копию crontab в

/bin. Это комментируется повсюду и заканчивается строкой # EOF , Это загружается ежедневно из записи в crontab, например:

Приведенная выше команда reload опирается на исполняемый файл crontab с путём взрыва, на котором выполняется crontab. В некоторых системах требуется запуск crontab в команде и указание файла. Если каталог является сетевым, то я часто использую crontab.$(hostname) как имя файла. Это в конечном итоге исправит случаи, когда неправильный crontab загружается на неправильный сервер.

Использование файла обеспечивает резервное копирование того, каким должен быть crontab, и позволяет выполнять временные изменения (единственный раз, когда я использую crontab -e ) для автоматического возврата. Доступны заголовки, которые помогают правильно настроить параметры планирования. Я добавил их, когда неопытные пользователи будут редактировать crontab.

Редко я сталкивался с командами, которые требуют ввода пользователя. Они терпят неудачу при crontab, хотя некоторые будут работать с перенаправлением ввода.

Источник

cron не работает, если в конце crontab нет перевода строки

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

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

вот собственно сам код

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

то есть если помимо первой строки, есть ещё какая то строка (хоть даже пустая), то всё работает, если 1 задача — то нет, и никаких ошибок в логах крона нет, что за бред? спасибо

2 ответа 2

TL;DR: Это не баг, а фича (c)

cron requires that each entry in a crontab end in a newline character. If the last entry in a crontab is missing a newline (ie, terminated by EOF), cron will consider the crontab (at least partially) broken. A warning will be written to syslog.

Что так и означает, что каждая запись в файле crontab должна оканчиваться символом перевода строки, в т.ч. и последняя. В противном случае cron игнорирует её и записывает предупреждение в системный журнал. Прочитать его можно командой tail /var/log/syslog .

Стоит заметить, что парсер crontab, используемый в systemd, лишён такой проблемы.

Последняя строка
Даже в современных изданиях ОС UNIX и Linux отсутствие перевода строки в конце системных конфигурационных файлов приводит к тому, что последняя строка не учитывается, а казалось бы правильно составленный файл не работает, представляясь головоломкой для пользователя, не предупреждённого об этой самобытной особенности.

«нормальные» редакторы всегда вставляют в конец файла символ lf (line feed, оно же \n , шестнадцатиричное значение 0a ).

если вы не уверены в используемом редакторе (в частности, например, если используете для редактирования файла какой-нибудь веб-интерфейс вместо редактора), вставляйте этот символ «руками»: переместите курсор в конец последней строки и нажмите enter .

Всё ещё ищете ответ? Посмотрите другие вопросы с метками linux cron crontab или задайте свой вопрос.

Похожие

Подписаться на ленту

Для подписки на ленту скопируйте и вставьте эту ссылку в вашу программу для чтения RSS.

дизайн сайта / логотип © 2021 Stack Exchange Inc; материалы пользователей предоставляются на условиях лицензии cc by-sa. rev 2021.10.15.40479

Нажимая «Принять все файлы cookie» вы соглашаетесь, что Stack Exchange может хранить файлы cookie на вашем устройстве и раскрывать информацию в соответствии с нашей Политикой в отношении файлов cookie.

Источник

Почему не запускается cron скрипт?

Помогите неопытному. Операционная система CentOS 6.3. Пытаюсь настроить бэкап папки и базы данных через rsync. Скрипты через консоль запускаются нормально, все работает, крон ошибок при сохранении не выдает, просто пишет «installing new crontab». Если я все правильно понимаю, то вроде все правильно. Но почему-то ничего не работает. Права на папку где лежат скрипты 777.

Я уже по всякому попробовал и /bin/bash в crontab убирал, поскольку как я прочитал, если в начале скрипта стоит #!/bin/bash , то это не нужно.

• Вопрос задан более трёх лет назад
• 41526 просмотров

Все нашел ответ на свой вопрос:

1) Кронтаб нужно запускать так: sudo crontab -e — это нужно чтобы cron запускал скрипты из под root.
2) Инструкции для cron должны быть такими. Нужно обязательно писать bash перед указанием пути к скрипту. После указания пути к скрипту дописать >/dev/null 2>&1
Пример:

3) Сами скрипты действительно должны быть лишены sudo, так как и так запускаются из под пользователя root.
Пример:

Можете объяснить что значит: >/dev/null 2>&1
У меня прописано сейчас вот так:
00 16,18,20,22 * * * garanty /home/garanty/www/garancy.finexpert.pro/ftpset.sh 2>/home/garanty/www/garancy.finexpert.pro/tmp/logscron.txt

Не запускается, хотя в логах пишет, что все нормально.

2>/home/garanty/www/garancy.finexpert.pro/tmp/logscron.txt — эта штука должна записывать в файл logscron.txt ошибки если они будут?

> Можете объяснить что значит: >/dev/null 2>&1
stdout — в /dev/null, stderr — туда же, куда stdout

Источник