Часто, crontab сценарии не выполняются по расписанию или как ожидается. Для этого есть множество причин:
- неправильная запись crontab
- проблема с разрешениями
- переменные среды
Вики-сообщество призвано объединить основные причины crontab сценарии не выполняются, как ожидалось. Запишите каждую причину в отдельном ответе.
Пожалуйста, включите одну причину для ответа — подробности о том, почему он не выполнен — и исправьте (и) по этой одной причине.
Пожалуйста, пишите только специфичные для cron проблемы, например команды, которые выполняются как ожидается от оболочки, но ошибочно выполняются cron.
Adam Matan 24 янв ’11 в 09:56 2011-01-24 09:56
2011-01-24 09:56
47 ответов
Другая среда
Cron передает минимальный набор переменных среды для ваших заданий. Чтобы увидеть разницу, добавьте фиктивную работу вот так:
* * * * * env> /tmp/env.output
Ждать /tmp/env.output чтобы быть созданным, затем удалите работу снова. Теперь сравните содержимое /tmp/env.output с выходом env запустить в своем обычном терминале.
Разбираемся с CRON | Теория | Практика | UnixHost
Распространенная «гоча» здесь PATH Переменная окружения отличается. Может быть, ваш скрипт cron использует команду somecommand нашел в /opt/someApp/bin , который вы добавили в PATH в /etc/environment ? Крон игнорирует PATH из этого файла, так что бег 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
geirha 26 янв ’11 в 21:19 2011-01-26 21:19
2011-01-26 21:19
Мой главный вопрос: если вы забудете добавить новую строку в конце 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)
user4124 26 янв ’11 в 12:27 2011-01-26 12:27
2011-01-26 12:27
Запуск задач по расписанию linux. Cron и его маленький секрет
Cron демон не работает. Я действительно облажался с этим несколько месяцев назад.
pgrep cron
Если вы не видите номера, значит, cron не запущен. sudo /etc/init.d/cron start можно использовать для запуска cron.
РЕДАКТИРОВАТЬ: Вместо того, чтобы вызывать сценарии инициализации через /etc/init.d, используйте служебную утилиту, например
sudo service cron start
aneeshep 27 янв ’11 в 04:06 2011-01-27 04:06
2011-01-27 04:06
Имя файла скрипта в cron.d/ , cron.daily/ , cron.hourly/ и т. д., не должны содержать точку ( . ), иначе run-parts пропустит их.
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/ каталог, вам лучше удалить имена расширений.
Xiè Jìléi 08 мар ’12 в 02:35 2012-03-08 02:35
2012-03-08 02:35
Во многих средах cron выполняет команды, используя sh в то время как многие люди предполагают, что он будет использовать bash ,
Предложения для проверки или исправления ошибки команды:
-
Попробуйте запустить команду в sh чтобы увидеть, работает ли это:
sh -c «mycommand»
bash -c «mybashcommand»
SHELL=/bin/bash
#!/bin/bash
Ian Mackinnon 25 июн ’11 в 19:30 2011-06-25 19:30
2011-06-25 19:30
У меня были некоторые проблемы с часовыми поясами.
Cron работал со свежим часовым поясом установки. Решение было перезапустить cron:
sudo service cron restart
luissquall 07 фев ’12 в 14:49 2012-02-07 14:49
2012-02-07 14:49
Абсолютный путь должен использоваться для скриптов:
Например, /bin/grep следует использовать вместо grep :
# m h dom mon dow command 0 0 * * * /bin/grep ERROR /home/adam/run.log /tmp/errors
# m h dom mon dow command 0 0 * * * grep ERROR /home/adam/run.log /tmp/errors
Это особенно сложно, потому что та же команда будет работать при запуске из оболочки. Причина в том, что cron не имеет то же самое PATH переменная окружения как пользователь.
Adam Matan 24 янв ’11 в 10:02 2011-01-24 10:02
2011-01-24 10:02
Если ваша команда crontab имеет % символ в этом, cron пытается интерпретировать это. Так что, если вы использовали какую-либо команду с % в нем (например, указание формата для команды date) вам необходимо его избежать.
JMS 22 фев ’12 в 06:29 2012-02-22 06:29
2012-02-22 06:29
Cron вызывает скрипт, который не является исполняемым.
Запустив chmod +x /path/to/scrip скрипт становится исполняемым и должен решить эту проблему.
jet 26 янв ’11 в 13:46 2011-01-26 13:46
2011-01-26 13:46
Также возможно, что срок действия пароля пользователя истек. Даже пароль root может истечь. Вы можете tail -f /var/log/cron.log и вы увидите сбой cron с истекшим сроком действия пароля. Вы можете установить пароль, чтобы никогда не истек, делая это: passwd -x -1
В некоторых системах (Debian, Ubuntu) ведение журнала для cron не включено по умолчанию. В /etc/rsyslog.conf или /etc/rsyslog.d/50-default.conf строка:
# cron.* /var/log/cron.log
следует отредактировать ( sudo nano /etc/rsyslog.conf ) оставлено без комментариев:
cron.* /var/log/cron.log
После этого вам нужно перезапустить rsyslog через
/etc/init.d/rsyslog restart
service rsyslog restart
В некоторых системах (Ubuntu) отдельный файл регистрации для cron не включен по умолчанию, но связанные с cron журналы появляются в файле syslog. Можно использовать
cat /var/log/syslog | grep cron -i
для просмотра сообщений, связанных с cron.
Daniel Tet 01 мар ’12 в 00:03 2012-03-01 00:03
2012-03-01 00:03
Если ваш cronjob вызывает GUI-приложения, вы должны сообщить им, какой DISPLAY они должны использовать.
Пример: запуск Firefox с помощью cron.
Ваш скрипт должен содержать export DISPLAY=:0 где-то.
andrew 02 янв ’12 в 12:42 2012-01-02 12:42
2012-01-02 12:42
Небезопасное разрешение таблицы cron
Таблица cron отклоняется, если ее разрешение небезопасно
sudo service cron restart grep -i cron /var/log/syslog|tail -2 2013-02-05T03:47:49.283841+01:00 ubuntu cron[49906]: (user) INSECURE MODE (mode 0600 expected) (crontabs/user)
Проблема решена с
# correct permission sudo chmod 600 /var/spool/cron/crontabs/user # signal crond to reload the file sudo touch /var/spool/cron/crontabs
John Peterson 05 фев ’13 в 02:51 2013-02-05 02:51
2013-02-05 02:51
Боюсь, проблемы с разрешениями встречаются довольно часто.
Обратите внимание, что распространенным обходным решением является выполнение всего, используя crontab root, который иногда является действительно плохой идеей. Установка правильных разрешений — определенно упущенная проблема.
26 янв ’11 в 15:53 2011-01-26 15:53
2011-01-26 15:53
Сценарий зависит от местоположения. Это связано с тем, что в скрипте всегда используются абсолютные пути, но это не совсем одно и то же. Ваша работа 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
pjmorse 02 фев ’11 в 19:55 2011-02-02 19:55
2011-02-02 19:55
Спецификации 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 или подобное, когда происходит обратное.
pbr 27 янв ’11 в 05:47 2011-01-27 05:47
2011-01-27 05:47
Самая частая причина, по которой я видел сбой 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, например:
#! / USR / бен / кронтаб # Перезагрузить этот crontab # 54 12 * * * $/bin/crontab
Приведенная выше команда reload опирается на исполняемый файл crontab с путём взрыва, на котором выполняется crontab. В некоторых системах требуется запуск crontab в команде и указание файла. Если каталог является сетевым, то я часто использую crontab.$(hostname) как имя файла. Это в конечном итоге исправит случаи, когда неправильный crontab загружается на неправильный сервер.
Использование файла обеспечивает резервное копирование того, каким должен быть crontab, и позволяет выполнять временные изменения (единственный раз, когда я использую crontab -e ) для автоматического возврата. Доступны заголовки, которые помогают правильно настроить параметры планирования. Я добавил их, когда неопытные пользователи будут редактировать crontab.
Редко я сталкивался с командами, которые требуют ввода пользователя. Они терпят неудачу при crontab, хотя некоторые будут работать с перенаправлением ввода.
Источник: ask-ubuntu.ru
Отслеживание CRON или что делать если задание CRON не выполняется
Если CRON не выполняется — причины может быть две — конфигурация самой службы на сервере и скрипт, который помещен в CRON. Начинать диагностику всегда следует с просмотра логов.
Что делать если задание CRON не выполняется
CRON — служба, которая по установленному расписанию выполняет задание. При этом процесс не отслеживается и если в задании допущен ошибка и ошибки содержит скрипт, добавленный в CRON, ожидаемого результата не будет и будет выглядеть как будто CRON задание не выполняется.
Задание в общем случае выглядит так:
5 4 * * * cd /home/site/ /usr/bin/php somescript.php
Если в результате выполнения скрипта, должны обновляться какие-то данные и обновление не происходит следует прежде всего попробовать запускать задание из консоли. В примере задание не выполняется потому, что файл из задания отсутствует в нужном каталоге.
Т.е. авторизоваться на сервере по SSH с реквизитами пользователя для которого прописан CRON и затем выполнить
Если скрипт содержит ошибки — они будут выведены в консоль, когда ошибок нет — поможет разработчик скрипта и CRON ни при чем.
При отсутствии ошибок в скрипте и успешном его выполнении из консоли следует отслеживать сами срабатывания. Самый простой способ — анализ логов.
Демон CRON записывает информацию о каждом срабатывании в /var/log/syslog.
Также можно скорректировать задание таким образом, чтобы запись в лог была частью задания — например, добавив конструкцию echo `date` >> /var/log/cronlog
Задание примет такой вид
5 4 * * * cd /home/site/ /usr/bin/php somescript.php echo `date` >> /var/log/cronlog
Каждый раз при успешном выполнении скрипта в файл /var/log/cronlog будет дописываться время выполнения. Если время дописывается — задание выполняется успешно.
Источник: server-gu.ru
Почему не запускается cron скрипт?
Помогите неопытному. Операционная система CentOS 6.3. Пытаюсь настроить бэкап папки и базы данных через rsync. Скрипты через консоль запускаются нормально, все работает, крон ошибок при сохранении не выдает, просто пишет «installing new crontab». Если я все правильно понимаю, то вроде все правильно.
Но почему-то ничего не работает. Права на папку где лежат скрипты 777.
Сами скрипты:
Первый
#!/bin/bash cd /mnt/backup/neon_backup/MySQL_backup mysqldump -u root -pnppwd —all-databases > mysql_backup.sql tar cvjf back_mysql.tar.bz2 mysql_backup.sql
#!/bin/bash sudo rsync —archive /home/share —delete /mnt/backup/neon_backup sudo rsync —archive /var/www/html/vtgr —delete /mnt/backup/neon_backup
#!/bin/bash sudo rsync —archive /var/www/html/vtgr —delete /mnt/backup/neon_backup/vtgr_weekly cd /mnt/backup/neon_backup/vtgr_weekly/MySQL_weekly mysqldump -u root -pnppwd —all-databases > mysql_backup.sql tar cvjf back_mysql.tar.bz2 mysql_backup.sql
Текст crontab
0 1 * * * /bin/bash /usr/share/script.sh 0 2 * * * /bin/bash /usr/share/script2.sh * * * * 1 /bin/bash /usr/share/script3.sh 30 4 * * * /var/www/vtgr/script/updateControlWorker.php 30 4 * * * /var/www/vtgr/script/createTack.php
Я уже по всякому попробовал и /bin/bash в crontab убирал, поскольку как я прочитал, если в начале скрипта стоит #!/bin/bash , то это не нужно.
- Вопрос задан более трёх лет назад
- 50475 просмотров
1 комментарий
Простой 1 комментарий
sudo rsync
Прикольно.
А кто пароль вводить будет?
Решения вопроса 1
C#/.NET back-end разработчик
Все нашел ответ на свой вопрос:
1) Кронтаб нужно запускать так: sudo crontab -e — это нужно чтобы cron запускал скрипты из под root.
2) Инструкции для cron должны быть такими. Нужно обязательно писать bash перед указанием пути к скрипту. После указания пути к скрипту дописать >/dev/null 2>/dev/null 2>/dev/null 2>/dev/null 2> mysql_backup.sql set > /tmp/script-environment tar cvjf back_mysql.tar.bz2 mysql_backup.sql
Ответ написан более трёх лет назад
Комментировать
Нравится 10 Комментировать
Ответы на вопрос 6
Opensource geek
В crontab в конец каждой команды добавьте:
> /tmp/имя_команды.log 2> /tmp/tmp_crontab sudo crontab -f /tmp/tmp_crontab
Это нужно добавить в начало скрипта?
нет, выполнить просто
Пишет неверный ключ —f
1. /bin/bash в crontab не нужен. Выкиньте его и сделайте скрипты исполняемыми.
2. приложения из cron запускаются с минимальным environment, если mysqldump не лежит в /bin или /usr/bin, script.sh его не найдёт. Добавьте в скрипт set > /tmp/script-environment чтобы посмотреть, с чем они запускаются.
3. sudo — нужен nopasswd
Ответ написан более трёх лет назад
Нравится 2 2 комментария
Можете объяснить что значит: >/dev/null 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> 2>/home/garanty/www/garancy.finexpert.pro/tmp/logscron.txt — эта штука должна записывать в файл logscron.txt ошибки если они будут?
да, ошибки выводимые garanty
Программирую немного )
1. Избавьтесь от sudo. Выполняйте крон от того пользователя у которого есть права без sudo.
2. Посмотрите логи крона.
Ответ написан более трёх лет назад
Нравится 1 1 комментарий
Это лог крона. Если я правильно понял, то все выполняется. Так?
Dec 18 21:00:01 server-centos CROND[7100]: (root) CMD (/usr/share/script.sh)
Dec 18 21:00:01 server-centos CROND[7101]: (root) CMD (/usr/share/script3.sh)
Dec 18 21:01:01 server-centos CROND[7111]: (root) CMD (run-parts /etc/cron.hourly)
Dec 18 21:01:01 server-centos run-parts(/etc/cron.hourly)[7111]: starting 0anacron
Dec 18 21:01:01 server-centos CROND[7112]: (root) CMD (/usr/share/script3.sh)
Dec 18 21:01:01 server-centos run-parts(/etc/cron.hourly)[7122]: finished 0anacron
Dec 18 21:02:01 server-centos CROND[7126]: (root) CMD (/usr/share/script3.sh)
Dec 18 21:03:01 server-centos CROND[7132]: (root) CMD (/usr/share/script3.sh)
Dec 18 21:04:01 server-centos CROND[7137]: (root) CMD (/usr/share/script3.sh)
Dec 18 21:05:01 server-centos CROND[7142]: (root) CMD (/usr/share/script3.sh)
Dec 18 21:06:01 server-centos CROND[7148]: (root) CMD (/usr/share/script3.sh)
Dec 18 21:07:01 server-centos CROND[7153]: (root) CMD (/usr/share/script3.sh)
Dec 18 21:08:01 server-centos CROND[7159]: (root) CMD (/usr/share/script3.sh)
Dec 18 21:09:01 server-centos CROND[7166]: (root) CMD (/usr/share/script3.sh)
Dec 18 21:10:01 server-centos CROND[7172]: (root) CMD (/usr/share/script3.sh)
Dec 18 21:11:01 server-centos CROND[7178]: (root) CMD (/usr/share/script3.sh)
Dec 18 21:12:01 server-centos CROND[7185]: (root) CMD (/usr/share/script3.sh)
Dec 18 21:13:01 server-centos CROND[7190]: (root) CMD (/usr/share/script3.sh)
Dec 18 21:14:01 server-centos CROND[7195]: (root) CMD (/usr/share/script3.sh)
Dec 18 21:15:01 server-centos CROND[7202]: (root) CMD (/usr/share/script3.sh)
Dec 18 21:15:01 server-centos CROND[7203]: (server) CMD (/usr/share/script.sh)
Dec 18 21:15:01 server-centos CROND[7205]: (root) CMD (/usr/share/script.sh)
Dec 18 21:16:01 server-centos CROND[7215]: (root) CMD (/usr/share/script3.sh)
Dec 18 21:17:01 server-centos CROND[7220]: (root) CMD (/usr/share/script3.sh)
Dec 18 21:18:01 server-centos CROND[7225]: (root) CMD (/usr/share/script3.sh)
Dec 18 21:19:01 server-centos CROND[7232]: (root) CMD (/usr/share/script3.sh)
Dec 18 21:20:01 server-centos CROND[7237]: (root) CMD (/usr/share/script3.sh)
Dec 18 21:21:01 server-centos CROND[7243]: (root) CMD (/usr/share/script3.sh)
Dec 18 21:22:01 server-centos CROND[7248]: (root) CMD (/usr/share/script3.sh)
Dec 18 21:23:01 server-centos CROND[7253]: (root) CMD (/usr/share/script3.sh)
Dec 18 21:24:01 server-centos CROND[7259]: (root) CMD (/usr/share/script3.sh)
Dec 18 21:25:01 server-centos CROND[7264]: (root) CMD (/usr/share/script3.sh)
Dec 18 21:26:01 server-centos CROND[7270]: (root) CMD (/usr/share/script3.sh)
Dec 18 21:27:01 server-centos CROND[7275]: (root) CMD (/usr/share/script3.sh)
Dec 18 21:28:01 server-centos CROND[7280]: (root) CMD (/usr/share/script3.sh)
Dec 18 21:29:01 server-centos CROND[7299]: (root) CMD (/usr/share/script3.sh)
Dec 18 21:30:01 server-centos CROND[7325]: (root) CMD (/usr/share/script.sh)
Dec 18 21:30:01 server-centos CROND[7326]: (root) CMD (/usr/share/script3.sh)
Dec 18 21:31:01 server-centos CROND[7355]: (root) CMD (/usr/share/script3.sh)
Dec 18 21:32:01 server-centos CROND[7380]: (root) CMD (/usr/share/script3.sh)
Dec 18 21:33:01 server-centos CROND[7405]: (root) CMD (/usr/share/script3.sh)
Dec 18 21:34:01 server-centos CROND[7430]: (root) CMD (/usr/share/script3.sh)
Dec 18 21:35:01 server-centos CROND[7455]: (root) CMD (/usr/share/script3.sh)
Dec 18 21:36:01 server-centos CROND[7481]: (root) CMD (/usr/share/script3.sh)
Dec 18 21:37:01 server-centos CROND[7506]: (root) CMD (/usr/share/script3.sh)
Dec 18 21:38:01 server-centos CROND[7531]: (root) CMD (/usr/share/script3.sh)
Dec 18 21:39:01 server-centos CROND[7556]: (root) CMD (/usr/share/script3.sh)
Dec 18 21:40:01 server-centos CROND[7581]: (root) CMD (/usr/share/script3.sh)
Dec 18 21:41:01 server-centos CROND[7607]: (root) CMD (/usr/share/script3.sh)
Источник: qna.habr.com