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

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.

EDIT: вместо вызова сценариев инициализации через /etc/init.d используйте служебную утилиту, например

sudo service cron start

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

(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.

Предложения по проверке или исправлению этого для команды сбоя:

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

sudo service cron restart

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

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

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

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

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

cat /var/log/syslog | grep 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 в конкретный каталог. задача rake в приложении Rails, возможно, должна быть в корне приложения для Rake для поиска правильной задачи, не говоря уже о соответствующей конфигурации базы данных и т. д.

Итак, запись crontab из

23 3 * * * /usr/bin/rake db:session_purge RAILS_ENV=production

будет лучше, чем

Или, чтобы сохранить вход crontab проще и менее хрупким:

23 3 * * * /home/<user>/scripts/session-purge.sh

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

Это приведет к ошибкам, указывающим на такие вещи, как , которые работали в прошлом , когда вы перемещаете команду из /etc/crontab или файла в [ f5] в файл crontab пользователя.

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

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

У меня был сценарий cron сбой, потому что я был в автопилоте, набирая скрипт, и я включил параметр -verbose: [!d1 ]

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

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

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

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

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

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

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

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

Все, что вам нужно do запускается:

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

В моем случае у 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 для моей учетной записи «Пользователь». Из чтения, которое я сделал, похоже, что это потенциальная проблема безопасности, но я единственный администратор в одной домашней сети, поэтому я решил, что все в порядке.

Вот последовательность команд, которая заставила меня двигаться: [ ! d3]

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. Мои два gotchas:

Проблема разрешения появится в /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, а затем к файлу, который я помещал под [ f8].

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

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

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

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

, чтобы узнать, помогает ли эта проблема.

Линия, написанная так, как не понимает 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 (что, как ни странно, не вызывает ошибки при прохождении [ f4]).

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

Создав то, что Аарон Пирт упомянул в режиме подробностей, иногда сценарии, не в подробном режиме, будут инициализированы, но не закончатся, если поведение по умолчанию включенной команды заключается в выводе строки или более на экран после запуска proc. Например, я написал сценарий резервного копирования для нашей интрасети, который использовал curl, утилиту, которая загружает или загружает файлы на удаленные серверы, и весьма удобна, если вы можете обращаться к указанным удаленным файлам через HTTP. Использование «curl http://something.com/somefile.xls» вызывало сценарий, который я написал, чтобы висеть и никогда не заканчиваться, потому что он выплескивает новую строку, за которой следует строка прогресса. Я должен был использовать молчащий флаг (-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 с помощью редактора Windows (через samba или что-то еще) и заменили строки с помощью \ n \ r или просто \ r, cron не будет запущен.

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

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

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

В 16.04, если у вас есть эта ошибка в syslog

(CRON) error (can't fork)

try:

systemctl status cron.service

В результате:

Tasks: num_task (limit: 512)

If num_task близок к использованию предела:

systemctl set-property cron.service TasksMax=new_max

Замените new_max на подходящее значение.