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

Разная среда

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

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

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

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

My top gotcha: Если вы забыли добавить новую строку в конце файла 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

Имена файлов сценариев в 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 , чтобы увидеть, работает ли она
• Обмотайте команду в подоболочке bash, чтобы убедиться, что она запущена в bash:
  bash -c "mybashcommand"
• Сообщите cron, чтобы запустить все команды в bash, установив оболочку в верхней части вашего crontab:
  SHELL=/bin/bash
• Если команда является скриптом, убедитесь, что скрипт содержит shebang:
  #!/bin/bash

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

sudo service cron restart

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

Это и другие хорошие результаты здесь:
Ссылка

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

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

Возможно также, что пароль пользователя истек. Даже пароль root может истек. Вы можете tail -f /var/log/cron.log , и вы увидите cron fail с истекшим паролем. Вы можете установить, чтобы пароль никогда не истекал, выполнив следующее: 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

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

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

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

Если ваш 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 в конкретном каталоге. задача рейка в приложении 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 системы есть дополнительное поле «пользователь» прямо перед командой для запуска.

Это приведет к ошибкам, указывающим на такие вещи, как 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, потому что подробный вывод идет на stdout при запуске из оболочки, но нигде не запускается crontab. Легко исправить удаление 'v':

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

Наиболее частая причина, по которой я видел cron, не соответствует неверно указанному графику. Для задания задания, запланированного на 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 , поэтому будут запускаться только стандартные команды. Обычно эти каталоги не имеют требуемой команды. Это также влияет на скрипты с использованием нестандартных команд. Другие переменные среды также могут отсутствовать.

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

#!/usr/bin/crontab
# Reload this crontab
#
54 12    *   *   *   ${HOME}/bin/crontab

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

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

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

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

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

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

Oct 24 07:51:00 mybox cron[29024]: [ID 731128 auth.notice] pam_unix_account: cron attempting to validate locked account myuser from local host
Oct 24 07:52:00 mybox cron[29063]: [ID 731128 auth.notice] pam_unix_account: cron attempting to validate locked account myuser from local host
Oct 24 07:53:00 mybox cron[29098]: [ID 731128 auth.notice] pam_unix_account: cron attempting to validate locked account myuser from local host
Oct 24 07:54:00 mybox cron[29527]: [ID 731128 auth.notice] pam_unix_account: cron attempting to validate locked account myuser from local host

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

# passwd -u <USERNAME>

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

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

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

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

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

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

В моем случае у 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 ~ $

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

Я создал файл mycronjob с расписанием cron, username & amp; и скопировали его в каталог /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 .

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

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

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

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

Изменить: Еще одна проблема - мне также не удалось заставить ее работать при запуске контейнера с сетью HOST. См. Также эту проблему: Ссылка

Линия, написанная так, как не понимает crontab. Он должен быть правильно написан. Вот CrontabHowTo .

Демон Cron может работать, но фактически не работает. Попробуйте перезапустить cron:

sudo /etc/init.d/cron restart

Запись в cron через «crontab -e» с аргументом имени пользователя в строке. Я видел примеры пользователей (или системных администраторов), которые пишут свои сценарии оболочки и не понимают, почему они не автоматизируют. Аргумент «user» существует в файле / 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 в сценарии оболочки. Sloppy, но он работает. ИМХО, более изящный вариант заключается в том, чтобы поместить его в /etc/crontab с объявленным именем пользователя и соответствующими разрешениями, поэтому file_output переходит в нужное место и владельца.

Построение того, что Аарон Пирт упомянул в режиме подробностей, иногда скрипты, не находящиеся в сложном режиме, будут инициализироваться, но не закончить, если поведение по умолчанию включенной команды заключается в выводе строки или более на экран после запуска proc. Например, я написал сценарий резервного копирования для нашей интрасети, который использовал curl, утилиту, которая загружает или загружает файлы на удаленные серверы, и весьма удобна, если вы можете обращаться к указанным удаленным файлам через HTTP. Использование 'curl Ссылка ' вызывало сценарий, который я написал, чтобы висеть и никогда не заканчиваться, потому что он выплескивает новую строку, за которой следует строка прогресса. Я должен был использовать молчащий флаг (-s), чтобы сообщить ему не выводить какую-либо информацию и писать в моем собственном коде для обработки, если файл не удалось загрузить.

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

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

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

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

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

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

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