как узнать почему не выполняется скрипт в cron
Добрый день. Добавил в крон скрипт для архивации некоторых папок с ограниченным доступом. Если указываю root пользователем для запуска — все работает. Указываю другого, который так же имеет доступ к папкам — не работает. В логе крона указано, что задание было запущено. В /var/log/messages ничего нет. Как узнать, почему задание не отрабатывает?
Сообщение об ошибках уходят юзеру (в локальную почту), от крона которого запускают скрипт. Можешь глянуть в что-то типа /var/spool/mail или просто запустить mutt (от нужного юзера).
Но быть может скрипт просто подвисает в ожидании чего-то (как вариант)? В процессах его нигде не видно?
В почте смотрел — ничего нет. В процессах скрипт тоже не висит.
Ну тогда нужно смотреть в скрипт. Или сами отладку проведите, или сюда высыпайте — думаю общий разум осилит.
ошибка в абсолютном/относительном пути к файлу запуска
А вы из под этого юзера пытались скрипт запускать?
как узнать почему не выполняется скрипт в cron
Использовать логирование и отладку.
Если при запуске через шелл работает, а через крон нет, то может быть связано с переменной окружения $PATH. А вообще, да, логгирование в помощь.
Капитан очевидность вангует на кофейной гуще: у рута стоит /bin/bash интерпретатором, а у юзера — /bin/sh, а скрипт использует фичи баша и фейлится при их отсутствии в sh.
Если указываю root пользователем для запуска — все работает. Указываю другого, который так же имеет доступ к папкам — не работает.
Во первых входит ли пользователь в группу sudo? Во вторых есть ли файл /etc/cron.allow и прописан ли там пользователь?
Как узнать, почему задание не отрабатывает?
Попробуйте дописать перенаправление вывода в ваш лог файл
Спасибо. Ваш совет помог разобраться. Дело было в правах доступа к папкам со скриптом. Кстати, есть ли какие-то рекомендуемые места в системе для хранения скриптов, доступные всем юзерам?
Кстати, есть ли какие-то рекомендуемые места в системе для хранения скриптов, доступные всем юзерам?
Источник
linux-notes.org
Cron — это демон, который запускает задачи по указанному (заданному) времени и который работает в наиболее распространенных дистрибутивах Unix / Linux. Поскольку cronjobs основаны на времени, иногда необходимо проверить и убедиться, что задание выполнялось в запланированное время. Иногда люди настраивают cron чтобы они отправляли вывод скрипта через системную почту или перенаправляюте вывод в файл; однако не все кроны настроены одинаково, и мние из них, могут быть настроены на отправку вывода в /dev/null, и тем самым, препятствуя любой возможности проверить выполняемое задание.
Первое что стоит проверить — это наличие ПИДа по крону:
crond, если он не настроен иначе, будет отправлять сообщение журнала в syslog каждый раз, когда он вызывает запланированное задание. Самый простой способ проверить работу cron на попытку срабатываания задание, — это проверить лог-файл.
В зависимости от Unix/Linux ОС, данный файл может иметь другое название.
Если у вас, CentOS/Fedora/RedHat, то просмотреть нужно:
Можно отсеять ненужное и поискать только необходимую крон-джобу, например:
Собственно, все наглядно видно.
Если у вас, Ubuntu/Debian, то просмотреть нужно:
Иногда, системные администраторы меняют вывод крона и для того, чтобы проверить куда пишуться логи по cron-job-ам, выполните:
С вывода видно, что у меня используется стандартный файл.
Так же, стоит проверить как настраивали крон-джобы:
Возможно было перенаправление вывода в какой-то файл для дальнейшего анализа.
Стоит отметить, то — что некоторые кроны лежат тут:
Бывает некоторые задачи запихивают туда.
Чтобы запретить или разрешить добавление крон-задат, нужно прописать юзера в:
Так же, можно восспользоватся следующими командами для проверки статуса, запуска/остановки/перезапуска службы:
Это все действия были для Linux, но сейчас приведу пример и для mac os x.
Недавно мне пришлось отлаживать работу Cron и проверять, действительно ли она выполняется по заданному расписанию. Я начал искать и проверять все логи и… нашел вроде бы подходящий файл для этого:
Но в нем не было признаков логирования крона!
Включить logging для Cron в Mac OSX
Для перезапуска syslog-а, выполняем:
Проверяем что получилось!
А для помощи, можно вызвать:
А на этом, у меня все, статья «Проверка работы cron в Unix/Linux» завершена.
Добавить комментарий Отменить ответ
Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.
Источник
Как проверить что джобы с крона запускаются?
Что-то у меня нет результата. Демон крона запущен.
А с таймером что не так?
Его надо использовать вместо cron. Там всегда понятно, работает или нет, и если нет, то почему.
1. Где ты ожидаешь найти test1.txt? Задай полный путь.
2. К вопросу не особо относится, но ты уверен, что запускать питоноскрипт каждую секунду — хорошая идея?
Каждую минуту. Большинство вариантов cron не в курсе о секундах.
Его надо использовать вместо cron. Там всегда понятно, работает или нет, и если нет, то почему.
Это что еще за дрянь?
Это нормально сделанный cron.
/home/op/pycron/test1.py Куда еще полнее? Ну вроде ежеминутно должно.
Какая реализация крона?
Разрешено ли пользователям (не руту) пользоваться кроном?
Хз, но я делал sudo chmod a+x /home/op/pycron/test1.py
Действительно куда? Может хотя бы > /tmp/test1.txt
Ну раз ты ничего не знаешь, то я ничем помочь тебе не могу.
Это не имеет никакого отношения к cron.
Похоже проблема была действительно в этом, сделал джоб так
Как проверить что джобы с крона запускаются?
В логах должны быть записи о запуске той или иной команды. См. /var/log/cron, /var/log/syslog, /var/log/messages.
Может так выловишь результат?
Уже заработало, всем большое спасибо.
1. Нужно смотреть логи syslog/messages,/var/log/cron.log если у вас старые ОС, и systemctl|grep -i cron для поиска сервиса cron, и journalctl -u cronie.service — что-бы понять, запускалось ли задание или нет.
2. Если проблема не в запуске задания, а в выполнении команды, осуществляем запуск самой команды в консоли, что-бы понять выполняется ли она, если да то с ошибками ли, и что делать с ошибками. Если это bash-скрипт, лучше запускать его в режиме отладки, так
Где первая и последняя команды активируют отладку, и отключают её, соответственно.
Писать в своём скрипте свои логи?
Уже начал так делать, скрипт выполняет запрос к эластику и дропает старые документы по фильтру.
скрипт выполняет запрос к эластику и дропает старые документы по фильтру
Да какая разница, чо он там делает:
У тебя, наверное, $MAILTO пустой в кронтабе. По умолчанию крон шлёт выхлоп команды (если он есть) тебе на системную почту. В этом случае тебе должно было прийти вменяемое сообщение об ошибке записи в файл, например, и ты бы сразу понял, в чём дело.
На будущее выстави MAILTO в кронтабе и MAILCHECK в шелле, чтобы видеть эти сообщения.
Источник
Где регистрируются ошибки cron?
Если я cron неправильно настраиваю задания, они, по-видимому, перестают работать. Где мне искать журнал ошибок, чтобы понять, что пошло не так?
Как уже отмечали другие, cron отправит вам по электронной почте вывод любой программы, которую он запускает (если она есть). Итак, если вы не получите никакого вывода, в основном есть три возможности:
- crond не мог даже запустить оболочку для запуска программы или отправки электронной почты
- crond были проблемы с отправкой по почте, или почта была потеряна.
- программа не выдает никаких выходных данных (включая сообщения об ошибках)
Случай 1. маловероятен, но что-то должно было быть записано в журналах cron. Cron имеет собственную зарезервированную функцию системного журнала, поэтому вам нужно посмотреть /etc/syslog.conf (или эквивалентный файл в вашем дистрибутиве), чтобы увидеть, куда cron отправляются сообщения этой службы . Популярные направления включают в себя /var/log/cron , /var/log/messages и /var/log/syslog .
В случае 2. вы должны проверить журналы демона почтовой программы: сообщения от демона Cron обычно появляются как root@yourhost . Вы можете использовать MAILTO=. строку в файле crontab, чтобы cron отправлял электронную почту на определенный адрес, что должно облегчить поиск журналов демона почтовой программы. Например:
В случае 3. вы можете проверить, действительно ли программа была запущена, добавив другую команду, эффект которой вы можете легко проверить: например,
так что вы можете проверить crond , действительно ли что-то запускалось, посмотрев на mtime of /tmp/a_command_has_run .
Источник
Почему не работают скрипты crontab?
Часто, crontab сценарии не выполняются по расписанию или как ожидается. Для этого есть множество причин:
- неправильная запись crontab
- проблема с разрешениями
- переменные среды
Вики-сообщество призвано объединить основные причины 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, хотя некоторые будут работать с перенаправлением ввода.
Источник
