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

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

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

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

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

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

Другая среда

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

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

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

Общей «ошибкой» здесь является то, что PATHпеременная окружения отличается. Может быть , ваш хрон сценарий использует команду somecommandнайденную в /opt/someApp/bin, который вы добавили PATHв /etc/environment? cron игнорирует PATHэтот файл, поэтому запуск somecommandиз вашего скрипта завершится неудачно при запуске с cron, но будет работать при запуске в терминале. Стоит отметить, что переменные from /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

Мой главный вопрос: если вы забыли добавить новую 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)

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

Тип:

pgrep cron 

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

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

sudo service cron start

РЕДАКТИРОВАТЬ: Также вы можете использовать systemctl в современном Linux, например,

sudo systemctl start cron

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

Смотрите run-parts (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/каталоге вам лучше удалить имена расширений.

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

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

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

  sh -c "mycommand"
  

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

  bash -c "mybashcommand"
  

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

  SHELL=/bin/bash
  

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

  #!/bin/bash
  

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

sudo service cron restart

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

Например, /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переменной среды, что и пользователь.

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

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

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

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

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

В некоторых системах (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 

Источник: Включить ведение журнала crontab в Debian Linux

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

cat /var/log/syslog | grep cron -i

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

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

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

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

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

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

Небезопасное разрешение таблицы 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

Сценарий зависит от местоположения. Это связано с тем, что в скрипте всегда используются абсолютные пути, но это не совсем одно и то же. Ваша задача 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/<user>/scripts/session-purge.sh

со следующим кодом в /home/<user>/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 имеют дополнительное поле 'user' прямо перед командой для запуска.

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

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

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

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

#!/bin/bash
some commands
tar cvfz /my/archive/file.tar.gz /my/shared/directory
come more commands

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

#!/bin/bash
some commands
tar cfz /my/archive/file.tar.gz /my/shared/directory
some more commands

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

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

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

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

#! / USR / бен / кронтаб
# Перезагрузить этот crontab
#
54 12 * * * $ {HOME} / bin / crontab

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

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

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

Если вы получаете доступ к учетной записи с помощью ключей SSH, можно войти в учетную запись, но не заметить, что пароль учетной записи заблокирован (например, из-за истечения срока действия или попытки ввода неверного пароля)

Если система использует PAM и учетная запись заблокирована, это может остановить запуск cronjob. (Я проверял это на Solaris, но не на Ubuntu)

Подобные сообщения вы можете найти в / var / adm / messages:

24 октября 07:51:00 mybox cron [29024]: [ID 731128 auth.notice] pam_unix_account: cron пытается проверить заблокированный аккаунт myuser с локального хоста
24 октября, 07:52:00 mybox cron [29063]: [ID 731128 auth.notice] pam_unix_account: cron пытается проверить заблокированный аккаунт myuser с локального хоста
24 октября 07:53:00 mybox cron [29098]: [ID 731128 auth.notice] pam_unix_account: cron пытается проверить заблокированный аккаунт myuser с локального хоста
24 октября, 07:54:00 mybox cron [29527]: [ID 731128 auth.notice] pam_unix_account: cron пытается проверить заблокированный аккаунт myuser с локального хоста

Все, что вам нужно сделать, это запустить:

# passwd -u <ИМЯ ПОЛЬЗОВАТЕЛЯ>

как root, чтобы разблокировать учетную запись, и crontab должен снова работать.

Если у вас есть такая команда:

* * * * * /path/to/script >> /tmp/output

и это не работает, и вы не можете видеть какой-либо вывод, это не обязательно означает, что cron не работает. Сценарий может быть поврежден, и вывод будет передан в stderr, который не будет передан в / tmp / output. Проверьте, что это не так, записав этот вывод:

* * * * * /path/to/script >> /tmp/output 2>&1

чтобы увидеть, поможет ли это вам решить вашу проблему.

=== Предупреждение Docker ===

Если вы используете докер,

Я считаю правильным добавить, что мне не удалось заставить cron работать в фоновом режиме.

Чтобы запустить задание cron внутри контейнера, я использовал supervisor и запустил cron -fвместе с другим процессом.

Изменить: Еще одна проблема - мне также не удалось заставить его работать при запуске контейнера с сетью HOST. Смотрите эту проблему здесь также: https://github.com/phusion/baseimage-docker/issues/144

Я писал сценарий установки оболочки, который создает другой сценарий для очистки старых данных транзакций из базы данных. В качестве части задачи он должен был настроить ежедневную cronработу для запуска в произвольное время, когда загрузка базы данных была низкой.

Я создал файл mycronjobс расписанием cron, именем пользователя и командой и скопировал его в /etc/cron.dкаталог. Мои две ошибки:

1. mycronjob файл должен был принадлежать пользователю root для запуска
2. Я должен был установить права доступа к файлу 644 - 664 не будет работать.

Проблема с разрешением будет отображаться /var/log/syslogкак нечто похожее на:

Apr 24 18:30:01 ip-11-22-33-44 cron[40980]: (*system*) INSECURE MODE (group/other writable) (/etc/crontab)
Apr 24 18:30:01 ip-11-22-33-44 cron[40980]: (*system*) INSECURE MODE (group/other writable) (/etc/cron.d/user)

Первая строка относится к /etc/crontabфайлу, а вторая - к файлу, в который я поместил /etc/cront.d.

Строка написана так, что crontab не понимает. Это должно быть правильно написано. Вот CrontabHowTo .

Cron-демон может быть запущен, но на самом деле не работает. Попробуйте перезапустить cron:

sudo /etc/init.d/cron restart

Запись в cron через "crontab -e" с аргументом username в строке. Я видел примеры пользователей (или системных администраторов), пишущих свои сценарии оболочки и не понимающих, почему они не автоматизируют. Аргумент «пользователь» существует в / etc / crontab, но не в пользовательских файлах. так, например, ваш личный файл будет выглядеть примерно так:

# m h dom mon dow command

* * */2  *   *  /some/shell/script

тогда как / etc / crontab будет:

# m h dom mon dow user   command

* * */2  *   *  jdoe   /some/shell/script

Итак, почему вы делаете последнее? Ну, в зависимости от того, как вы хотите установить свои разрешения, это может стать очень запутанным. Я написал сценарии для автоматизации задач для пользователей, которые не разбираются в тонкостях или не хотят беспокоиться о тяжелой работе. Установив права доступа --x------, я могу сделать исполняемый скрипт без возможности его чтения (и, возможно, случайного изменения). Тем не менее, я мог бы захотеть запустить эту команду с несколькими другими из одного файла (таким образом, облегчая поддержку), но удостовериться, что выходной файл назначен правильному владельцу. Это (по крайней мере, в Ubuntu 10.10) устраняет как невозможность чтения файла, так и выполнения, а также вышеупомянутую проблему с помещением точек в / etc / crontab (что, как ни странно, не вызывает ошибок при прохождении crontab -e) ,

В качестве примера я видел примеры sudo crontab -eиспользования для запуска скрипта с правами root, с соответствующим chown username file_outputв скрипте оболочки. Небрежно, но это работает. ИМХО, более изящный вариант - поставить его /etc/crontabс объявленным именем пользователя и надлежащими разрешениями, поэтому file_outputотправляется в нужное место и владельцу.

Основываясь на том, что Аарон Пирт упомянул о подробном режиме, иногда сценарии, не находящиеся в подробном режиме, будут инициализироваться, но не завершаться, если поведение включенной команды по умолчанию будет выводить строку или более на экран после запуска процедуры. Например, я написал сценарий резервного копирования для нашей интрасети, который использовал curl, утилиту, которая загружает или загружает файлы на удаленные серверы, и это очень удобно, если вы можете получить доступ к указанным удаленным файлам только через HTTP. Использование 'curl http://something.com/somefile.xls ' приводило к зависанию написанного мной скрипта, который никогда не завершался, поскольку он выплевывал новую строку, за которой следовала строка прогресса. Мне пришлось использовать флаг без вывода сообщений (-s), чтобы запретить выводить какую-либо информацию, и написать собственный код для обработки, если файл не удалось загрузить.

Хотя вы можете определять переменные окружения в вашем crontable, вы не находитесь в сценарии оболочки. Поэтому конструкции, подобные следующим, не будут работать:

SOME_DIR=/var/log
MY_LOG_FILE=${SOME_LOG}/some_file.log

BIN_DIR=/usr/local/bin
MY_EXE=${BIN_DIR}/some_executable_file

0 10 * * * ${MY_EXE} some_param >> ${MY_LOG_FILE}

Это потому, что переменные не интерпретируются в crontable: все значения принимаются буквально. И это то же самое, если вы опустите скобки. Таким образом, ваши команды не будут выполняться, а ваши файлы журнала не будут записаны ...

Вместо этого вы должны определить все переменные окружения прямо:

SOME_DIR=/var/log
MY_LOG_FILE=/var/log/some_file.log

BIN_DIR=/usr/local/bin
MY_EXE=/usr/local/bin/some_executable_file

0 10 * * * ${MY_EXE} some_param >> ${MY_LOG_FILE}

Когда задача запускается в cron, stdin закрывается. Программы, которые работают по-разному в зависимости от того, доступен ли stdin или нет, будут вести себя по-разному между сеансом оболочки и в cron.

Примером является программа goaccessдля анализа файлов журнала веб-сервера. Это не работает в cron:

goaccess -a -f /var/log/nginx/access.log > output.html

и goaccessпоказывает страницу справки вместо создания отчета. В оболочке это можно воспроизвести с помощью

goaccess -a -f /var/log/nginx/access.log > output.html < /dev/null

Решение goaccessпроблемы - заставить его читать журнал из stdin вместо чтения из файла, поэтому решение состоит в том, чтобы изменить запись crontab на

cat /var/log/nginx/access.log | goaccess -a > output.html

В моем случае у cron и crontab были разные владельцы.

Не работает у меня было это:

User@Uva ~ $ ps -ef | grep cron | grep -v grep
User    2940    7284 pty1     19:58:41 /usr/bin/crontab
SYSTEM   11292     636 ?        22:14:15 /usr/sbin/cro 

В основном мне пришлось запустить cron-config и правильно ответить на вопросы. Есть момент, когда мне нужно было ввести мой пароль пользователя Win7 для моей учетной записи «Пользователь». После прочтения, похоже, это потенциальная проблема безопасности, но я единственный администратор в одной домашней сети, поэтому я решил, что все в порядке.

Вот последовательность команд, которая меня подтолкнула:

User@Uva ~ $ cron-config
The cron daemon can run as a service or as a job. The latter is not recommended.
Cron is already installed as a service under account LocalSystem.
Do you want to remove or reinstall it? (yes/no) yes
OK. The cron service was removed.

Do you want to install the cron daemon as a service? (yes/no) yes
Enter the value of CYGWIN for the daemon: [ ] ntsec

You must decide under what account the cron daemon will run.
If you are the only user on this machine, the daemon can run as yourself.
   This gives access to all network drives but only allows you as user.
To run multiple users, cron must change user context without knowing
  the passwords. There are three methods to do that, as explained in
  http://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-nopasswd1
If all the cron users have executed "passwd -R" (see man passwd),
  which provides access to network drives, or if you are using the
  cyglsa package, then cron should run under the local system account.
Otherwise you need to have or to create a privileged account.
  This script will help you do so.
Do you want the cron daemon to run as yourself? (yes/no) no

Were the passwords of all cron users saved with "passwd -R", or
are you using the cyglsa package ? (yes/no) no

Finding or creating a privileged user.
The following accounts were found: 'cyg_server' .
This script plans to use account cyg_server.
Do you want to use another privileged account name? (yes/no) yes
Enter the other name: User

Reenter: User


Account User already exists. Checking its privileges.
INFO: User is a valid privileged account.
INFO: The cygwin user name for account User is User.

Please enter the password for user 'User':
Reenter:
Running cron_diagnose ...
... no problem found.

Do you want to start the cron daemon as a service now? (yes/no) yes
OK. The cron daemon is now running.

In case of problem, examine the log file for cron,
/var/log/cron.log, and the Windows event log (using /usr/bin/cronevents)
for information about the problem cron is having.

Examine also any cron.log file in the HOME directory
(or the file specified in MAILTO) and cron related files in /tmp.

If you cannot fix the problem, then report it to cygwin@cygwin.com.
Please run the script /usr/bin/cronbug and ATTACH its output
(the file cronbug.txt) to your e-mail.

WARNING: PATH may be set differently under cron than in interactive shells.
         Names such as "find" and "date" may refer to Windows programs.


User@Uva ~ $ ps -ef | grep cron | grep -v grep
    User    2944   11780 ?        03:31:10 /usr/sbin/cron
    User    2940    7284 pty1     19:58:41 /usr/bin/crontab

User@Uva ~ $

На моих серверах RHEL7 запускаются задания root cron, а задания пользователей - нет. Я обнаружил, что без домашнего каталога задания не будут выполняться (но вы увидите хорошие ошибки в / var / log / cron). Когда я создал домашний каталог, проблема была решена.

Если вы отредактировали свой файл crontab с помощью редактора Windows (через samba или что-то еще), и он заменил символы новой строки на \ n \ r или просто \ r, cron не запустится.

Кроме того, если вы используете /etc/cron.d/* и в одном из этих файлов есть \ r, cron будет перемещаться по файлам и останавливаться, когда попадет в плохой файл. Не уверен, что это проблема?

Использование:

od -c /etc/cron.d/* | grep \r