crontab не выполняет скрипт
как узнать почему не выполняется скрипт в cron
Сообщение об ошибках уходят юзеру (в локальную почту), от крона которого запускают скрипт. Можешь глянуть в что-то типа /var/spool/mail или просто запустить mutt (от нужного юзера).
Но быть может скрипт просто подвисает в ожидании чего-то (как вариант)? В процессах его нигде не видно?
ошибка в абсолютном/относительном пути к файлу запуска
А вы из под этого юзера пытались скрипт запускать?
как узнать почему не выполняется скрипт в cron
Использовать логирование и отладку.
Во первых входит ли пользователь в группу sudo? Во вторых есть ли файл /etc/cron.allow и прописан ли там пользователь?
Как узнать, почему задание не отрабатывает?
Попробуйте дописать перенаправление вывода в ваш лог файл
Спасибо. Ваш совет помог разобраться. Дело было в правах доступа к папкам со скриптом. Кстати, есть ли какие-то рекомендуемые места в системе для хранения скриптов, доступные всем юзерам?
Кстати, есть ли какие-то рекомендуемые места в системе для хранения скриптов, доступные всем юзерам?
Планировщик cron: не выполняется пользовательский скрипт.?
2. В конкретно вашем случае вы используете системный кронтам, а не пользовательский.
/.bash_history будет относиться к текущему юзеру, который в данном случае будет root
Точно у рута не очищается хистори при ребуте?
upd. Сейчас попробую переместить скрипт в / и запустить.
В кронтабе не пользуйтесь подобными сокращениями и алиасами. Ставь полный путь и убедить в правах доступа.
Где из этого смотреть инфо про путь:
/etc/systemd/system/multi-user.target.wants/anacron.service
/etc/systemd/system/multi-user.target.wants/cron.service
/lib/systemd/system/anacron.service
/lib/systemd/system/cron.service
/var/lib/systemd/deb-systemd-helper-enabled/anacron.service.dsh-also
/var/lib/systemd/deb-systemd-helper-enabled/cron.service.dsh-also
/var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/anacron.service
/var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/cron.service
?
, с самого начала от /
Кому не лень, подскажите pls, в каком файле прописано, что помимо системных заданий демону cron необходимо выполнять также и пользовательские?
в системных кронтабах просто на одну колонку больше
# Minutes Hours Days Months WeekDays USER Command
как это работает с тегами @reboot не подскажу, надо документацию глянуть.
Но от рута всегда можно что-то сделать через su/sudo
Почему не работают скрипты crontab?
Часто crontab сценарии не выполняются по расписанию или как ожидалось. Для этого есть множество причин:
Вики-сообщество призвано объединить основные причины, по которым crontab скрипты выполняются не так, как ожидалось. Запишите каждую причину в отдельном ответе.
Пожалуйста, пишите только специфичные для cron проблемы, например команды, которые выполняются как ожидается от оболочки, но ошибочно выполняются cron.
Другая среда
Cron передает минимальный набор переменных среды для ваших заданий. Чтобы увидеть разницу, добавьте фиктивную работу вот так:
Дождитесь /tmp/env.output создания, затем снова удалите задание. Теперь сравните содержимое /tmp/env.output с выходом env запуска в обычном терминале.
Чтобы обойти это, просто установите свою собственную PATH переменную в верхней части скрипта. Например
Вы также можете установить переменную PATH в файле crontab, который будет применяться ко всем заданиям cron. Например
Мой главный вопрос: если вы забыли добавить новую crontab строку в конце файла. Другими словами, файл crontab должен заканчиваться пустой строкой.
Ниже приведен соответствующий раздел на страницах руководства для этой проблемы ( man crontab затем перейдите к концу):
Cron демон не работает. Я действительно облажался с этим несколько месяцев назад.
Если вы не видите номера, значит, cron не запущен. sudo /etc/init.d/cron start может быть использован для запуска cron.
РЕДАКТИРОВАТЬ: Вместо того, чтобы вызывать сценарии инициализации через /etc/init.d, используйте служебную утилиту, например
РЕДАКТИРОВАТЬ: Также вы можете использовать systemctl в современном Linux, например,
Смотрите run-parts (8):
Предложения для проверки или исправления ошибки команды:
Попробуйте запустить команду, sh чтобы увидеть, работает ли она:
Оберните команду в подоболочку bash, чтобы убедиться, что она запускается в bash:
Скажите cron запустить все команды в bash, установив оболочку в верхней части вашего crontab:
Если команда является скриптом, убедитесь, что скрипт содержит шебанг:
У меня были некоторые проблемы с часовыми поясами. Cron работал со свежим часовым поясом установки. Решение было перезапустить cron:
Абсолютный путь должен использоваться для скриптов:
Например, /bin/grep следует использовать вместо grep :
Это особенно сложно, потому что та же команда будет работать при запуске из оболочки. Причина в том, что cron не имеет той же PATH переменной среды, что и пользователь.
Если в вашей команде crontab есть % символ, cron пытается его интерпретировать. Поэтому, если вы использовали какую-либо команду, содержащую % в себе (например, спецификацию формата для команды date), вам нужно будет ее избежать.
Cron вызывает скрипт, который не является исполняемым.
При запуске chmod +x /path/to/scrip сценарий становится исполняемым и должен решить эту проблему.
В некоторых системах (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 где-то.
Боюсь, проблемы с разрешениями встречаются довольно часто.
Небезопасное разрешение таблицы 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 или похожие, когда произойдет обратное.
Сценарий выполнялся нормально при выполнении из оболочки, но не работал при запуске из crontab, поскольку подробный вывод выводится на стандартный вывод при запуске из оболочки, но нигде при запуске из crontab. Легко исправить, чтобы удалить «V»:
Использование неквалифицированных путей также вызвало проблемы. Путь по умолчанию обычно /bin:/usr/bin таков, что будут выполняться только стандартные команды. Эти каталоги обычно не имеют желаемой команды. Это также влияет на сценарии, использующие нестандартные команды. Другие переменные среды также могут отсутствовать.
Приведенная выше команда reload опирается на исполняемый файл crontab с путём взрыва, на котором выполняется crontab. В некоторых системах требуется запуск crontab в команде и указание файла. Если каталог является сетевым, то я часто использую crontab.$(hostname) в качестве имени файла. Это в конечном счете исправит случаи, когда неправильный crontab загружен на неправильный сервер.
Редко я сталкивался с командами, которые требуют ввода пользователя. Они терпят неудачу при crontab, хотя некоторые будут работать с перенаправлением ввода.
Почему скрипты crontab не работают?
Часто скрипты crontab не выполняются по расписанию или как ожидалось. Для этого существует множество причин:
неправильные разрешения для обозначения нот кнтабата.
Эта вики сообщества предназначена для объединения главных причин, по которым сценарии crontab не выполняются, как ожидалось. Напишите каждую причину в отдельном ответе.
29 ответов
My top gotcha: Если вы забыли добавить новую строку в конце файла crontab. Другими словами, файл crontab должен заканчиваться пустой строкой.
Ниже приведен соответствующий раздел на страницах руководства для этой проблемы (man crontab, затем пропустите до конца):
Демон Cron не работает.
Если вы не видите числа, cron не работает. sudo /etc/init.d/cron start можно использовать для запуска cron.
EDIT: вместо вызова сценариев инициализации через /etc/init.d используйте служебную утилиту, например
Имена файлов сценариев в файлах cron.d/, cron.daily/, cron.hourly/ и т. д. не должны содержать точку (.), в противном случае пробег будет пропущен.
Итак, если у вас есть cron-скрипт backup.sh, analyze-logs.pl в каталоге cron.daily/, лучше удалить имена расширений.
Во многих средах cron выполняет команды с использованием sh, в то время как многие полагают, что он будет использовать bash.
Предложения по проверке или исправлению этого для команды сбоя:
У меня были некоторые проблемы с часовыми поясами. Cron работал со свежим временем установки. Решением было перезапустить cron:
Если ваша команда crontab имеет в ней символ %, cron пытается ее интерпретировать. Поэтому, если вы использовали какую-либо команду с % в ней (например, спецификацию формата для команды date), вам нужно будет ее избежать.
Это и другие хорошие ошибки здесь: http: // www.pantz.org/software/cron/croninfo.html
Абсолютный путь должен использоваться для скриптов:
Например, вместо grep следует использовать /bin/grep:
Это особенно сложно, потому что одна и та же команда будет работать при выполнении из оболочки. Причина в том, что cron не имеет той же переменной среды PATH, что и пользователь.
В некоторых системах (Debian, Ubuntu) регистрация cron по умолчанию не включена. В файле /etc/rsyslog.conf или /etc/rsyslog.d/50-default.conf строка:
должна быть отредактирована (sudo nano /etc/rsyslog.conf) раскомментирована на:
После этого вам необходимо перезапустить rsyslog с помощью
Источник: Включить ведение журнала crontab в Debian Linux
In для некоторых систем (Ubuntu) отдельный файл регистрации для cron по умолчанию не включен, но связанные с cron журналы отображаются в файле syslog. Для просмотра сообщений, связанных с cron, можно использовать
Cron вызывает скрипт, который не является исполняемым.
При запуске chmod +x /path/to/scrip скрипт становится исполняемым и должен решить эту проблему.
Если ваш 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
23 3 * * * cd /var/www/production/current && /usr/bin/rake db:session_purge RAILS_ENV=production
Или, чтобы сохранить вход crontab проще и менее хрупким:
23 3 * * * /home/ /scripts/session-purge.sh
со следующим кодом в /home/ /scripts/session-purge.sh:
cd /var/www/production/current /usr/bin/rake db:session_purge RAILS_ENV=production
Спецификации Crontab, которые работали в прошлом, могут сломаться при перемещении из одного файла crontab в другой. Иногда причина в том, что вы переместили спецификацию из файла crontab системы в файл crontab пользователя или наоборот.
Формат спецификации заданий cron отличается между файлами crontab пользователей (/ var / spool / cron / username или / var / spool / cron / crontabs / username) и системы crontabs (/etc/crontab и файлы в /etc/cron.d).
В системе crontabs есть дополнительное поле «пользователь», прямо перед командой для запуска.
Наоборот, cron будет выдавать ошибки, такие как /usr/bin/restartxyz is not a valid username или подобное, когда происходит обратное.
Скрипт отлично работает при выполнении из оболочки, но не работает при запуске crontab, потому что подробный вывод идет на stdout при запуске из оболочки, но нигде не запускается crontab. Легко исправить удаление ‘v’:
Наиболее частая причина, по которой я видел cron fail в неверно заявленном графике. Для определения задания, запланированного на 11:15 вечера, требуется 30 23 * * * вместо * * 11 15 * или 11 15 * * *. День недели для работы после полуночи также путает M-F 2-6 после полуночи, а не 1-5. Конкретные даты обычно являются проблемой, поскольку мы редко используем их * * 3 1 * не является 3 марта.
Если ваша работа с различными платформами с использованием неподдерживаемых опций, таких как 2/3 во временных спецификациях, также может привести к сбоям. Это очень полезный вариант, но не универсальный. Я также столкнулся с проблемами, такими как 1-5 или 1,3,5.
Использование неквалифицированных путей также вызвало проблемы. Путь по умолчанию обычно /bin:/usr/bin, поэтому будут запускаться только стандартные команды. Обычно эти каталоги не имеют требуемой команды. Это также влияет на скрипты с использованием нестандартных команд. Другие переменные среды также могут отсутствовать.
/ bin. Он прокомментирован повсюду и заканчивается линией # EOF. Это перезагружается ежедневно с помощью записи crontab, например:
. Команда reload выше полагается на исполняемый crontab с пропуском crontab. Для некоторых систем требуется команда crontab в команде и указание файла. Если каталог является общим для сети, я часто использую crontab.$(hostname) как имя файла. Это будет в конечном итоге исправлять случаи, когда неправильный crontab загружается на неправильный сервер.
Редко, я столкнулся с командами, требующими ввода пользователем. Они не работают в режиме crontab, хотя некоторые из них будут работать с перенаправлением ввода.
Почему не работают скрипты crontab?
Часто, crontab сценарии не выполняются по расписанию или как ожидается. Для этого есть множество причин:
Вики-сообщество призвано объединить основные причины crontab сценарии не выполняются, как ожидалось. Запишите каждую причину в отдельном ответе.
Пожалуйста, пишите только специфичные для cron проблемы, например команды, которые выполняются как ожидается от оболочки, но ошибочно выполняются cron.
46 ответов
Другая среда
Cron передает минимальный набор переменных среды для ваших заданий. Чтобы увидеть разницу, добавьте фиктивную работу вот так:
Ждать /tmp/env.output чтобы быть созданным, затем удалите работу снова. Теперь сравните содержимое /tmp/env.output с выходом env запустить в своем обычном терминале.
Чтобы обойти это, просто установите свой собственный 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, используйте служебную утилиту, например
Предложения для проверки или исправления ошибки команды:
Попробуйте запустить команду в sh чтобы увидеть, работает ли это:
Оберните команду в подоболочку bash, чтобы убедиться, что она запускается в bash:
Скажите cron запустить все команды в bash, установив оболочку в верхней части вашего crontab:
Если команда является скриптом, убедитесь, что скрипт содержит шебанг:
У меня были некоторые проблемы с часовыми поясами. Cron работал со свежим часовым поясом установки. Решение было перезапустить cron:
Абсолютный путь должен использоваться для скриптов:
Например, /bin/grep следует использовать вместо grep :
Это особенно сложно, потому что та же команда будет работать при запуске из оболочки. Причина в том, что cron не имеет то же самое PATH переменная окружения как пользователь.
Если ваша команда crontab имеет % символ в этом, cron пытается интерпретировать это. Так что, если вы использовали какую-либо команду с % в нем (например, указание формата для команды date) вам необходимо его избежать.
Cron вызывает скрипт, который не является исполняемым.
Запустив chmod +x /path/to/scrip скрипт становится исполняемым и должен решить эту проблему.
В некоторых системах (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 где-то.
Боюсь, проблемы с разрешениями встречаются довольно часто.
Небезопасное разрешение таблицы 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 или подобное, когда происходит обратное.
Сценарий выполнялся нормально при выполнении из оболочки, но не работал при запуске из crontab, поскольку подробный вывод выводится на стандартный вывод при запуске из оболочки, но нигде при запуске из crontab. Легко исправить, чтобы удалить «V»:
Использование неквалифицированных путей также вызвало проблемы. Путь по умолчанию обычно /bin:/usr/bin поэтому будут выполняться только стандартные команды. Эти каталоги обычно не имеют желаемой команды. Это также влияет на сценарии, использующие нестандартные команды. Другие переменные среды также могут отсутствовать.
Приведенная выше команда reload опирается на исполняемый файл crontab с путём взрыва, на котором выполняется crontab. В некоторых системах требуется запуск crontab в команде и указание файла. Если каталог является сетевым, то я часто использую crontab.$(hostname) как имя файла. Это в конечном итоге исправит случаи, когда неправильный crontab загружается на неправильный сервер.
Редко я сталкивался с командами, которые требуют ввода пользователя. Они терпят неудачу при crontab, хотя некоторые будут работать с перенаправлением ввода.