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

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

Например, / 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

Также возможно, что срок действия пароля пользователя истек. Даже пароль 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 

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

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

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

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

Спецификации Crontab , которые работали в прошлом , могут сломаться при перемещении с одного crontab в другой. Иногда причина заключается в том, что вы переместили спецификацию из системного файла crontab в файл crontab пользователя или наоборот.

Формат спецификации задания cron отличается для файлов crontab пользователей (/ var / spool / cron / username или / var / spool / cron / crontabs / username) и системные crontab ( / etc / crontab и файлы в /etc/cron.d ).

Система crontabs имеет дополнительное поле «пользователь» прямо перед запускаемой командой.

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

И наоборот, cron выдаст ошибку типа / usr / bin / restartxyz не является допустимым именем пользователя или аналогичную, когда произойдет обратное.

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

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

Небезопасное разрешение таблицы 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 вызывает команду с параметром --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 вызывает приложения с графическим интерфейсом пользователя, вам необходимо указать им, какой ДИСПЛЕЙ им следует использовать.

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

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

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

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

Самая частая причина, по которой я видел, как cron выходит из строя из-за неправильно указанного расписания. Требуется практика, чтобы указать задание, запланированное на 23:15, как 15 23 * * * вместо * * 11 15 * или 11 15 * * * . День недели для работ после полуночи также путается. M – F 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/bin/crontab
# Reload this crontab
#
54 12    *   *   *   ${HOME}/bin/crontab

Вышеупомянутая команда перезагрузки полагается на исполняемый файл crontab с запуском crontab по пути bang. Некоторые системы требуют, чтобы в команде был запущен crontab и был указан файл. Если каталог является общим для сети, я часто использую crontab. $ (Hostname) в качестве имени файла. В конечном итоге это исправит случаи, когда неправильный crontab загружается не на тот сервер.

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

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

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

Если система использует PAM и аккаунт заблокирован, это может остановить его работу. (Я тестировал это на 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, чтобы разблокировать учетную запись, и кронтаб должен снова заработать.

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

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

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

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

посмотрим, поможет ли это поймать вашу проблему.

=== Оповещение о докере ===

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

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

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

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

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

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

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