Назад | Перейти на главную страницу

Определите проблему с неработающим CRON

Как я могу определить проблемы с /etc/crontab не запускаются команды cron? У меня есть сценарии, которые отправляют электронные письма, я могу запускать их вручную через командную строку, и они отлично работают, но никогда не обрабатываются cron ....

Что я могу сделать, чтобы выяснить, почему cron не работает?

У меня такое чувство, что это часть проблемы ...

$ sudo /etc/init.d/crond start
sudo: /etc/init.d/crond: command not found

У вас есть несколько вариантов, не в каком-то определенном порядке.

  • Запустите команду, которая у вас есть в crontab, в командной строке. Это может быть обманчивым, поскольку часто это срабатывает для вас, а причина, по которой он не работает в cron, - это отсутствующая переменная среды или что-то в этом роде.

  • Добавьте параметр вывода в строку crontab, например:

    5 */2 * * * /usr/local/bin/do-stuff.sh >> /tmp/results.log;

  • Убедитесь, что cron действительно запущен.

  • Проверьте файлы журнала cron на наличие конкретных ошибок.

В дополнение к ответам @muffinista и @brent есть и другие эзотерические проблемы, с которыми вы можете столкнуться в Ubuntu.

  • Вам нужна пустая строка в конце вашего crontab.
  • Пользователь должен находиться в | not-in /etc/cron.allow|cron.deny (или эти файлы должны отсутствовать)
    • пользователю не обязательно быть членом группы crontab
  • cron может игнорировать имена файлов, которые ему не нравятся, в /etc/cron.d/ и подобных каталогах.
    • добавить параметр cron '-l' (влияние более подробно описано в 'man run-parts')

  • cron отправляет записи crontab через / bin / sh (по умолчанию), поэтому такие простые вещи, как это, не работают, но работают при вставке в ваш терминал / bin / bash

    0 * * * * echo hi >& /dev/null

    так что измените SHELL или синтаксис перенаправления!

Моя версия Ubuntu игнорирует настройки в / etc / defaults / cron, поэтому для увеличения уровня журнала вам может потребоваться запустить демон cron вручную (cron -f -L 2).

В некоторых недавних случаях это происходило из-за того, что люди редактировали файлы в /etc/crontab без отправки crond сигнала 1 (SIGHUP), чтобы он знал, что он должен перечитать /etc/crontab файл.

Пытаться 

kill -1 $PID-OF-CROND

и посмотрите, поможет ли это. Определение pid crond остается для вас в качестве упражнения ;-) - не в последнюю очередь потому, что если вы не можете его найти, это может означать, что crond не работает, и тогда вы найдете свою проблему!

Если вы используете shellscript, люди часто забывают, что команды, которые они используют в своем скрипте, могут не находиться в PATH cron (например, что-то в /opt). При необходимости настройте ваш PATH в начале вашего скрипта. Для sh / bash это будет:

PATH=$PATH:/opt/something-1.0/bin

например