cron.daily задания не работают
Я создал 3 ежедневных задания cron для запуска.
Ниже приведены три, которые помещены в etc / cron.daily
rkhunter.sh
#!/bin/sh
(
rkhunter --versioncheck
rkhunter --update
rkhunter --cronjob --report-warnings-only
) | mail -s 'rkhunter Daily Run (my server)' me@email.com
chkrootkit.sh [ 117]
#!/bin/bash
chkrootkit | mail -s "chkrootkit Daily Run (my server)" me@email.com
logwatch.sh
#!/bin/sh
(
logwatch
) | mail -s 'logwatch Daily Log (my server)' me@email.com
Я заменил разметку me@email.com своей электронной почтой.
Если я запускаю этот cronjob вручную, он работает нормально ./nameoffile.sh
Но он не запускается ежедневно, в чем может быть причина или как я могу проверить это?
10 ответов
Есть два возможных подозреваемых, которые обычно вызывают невозможность запуска cron заданий.
Первый - это проблемы с разрешениями, то есть пользователь может запустить сценарий / команду, но демон cron не может, потому что задание находится в заданиях cron не того пользователя. Например, пользователь создает сценарий или запускает команду с повышенными привилегиями, то есть с помощью sudo , а затем добавляет проверенный сценарий / команду в свой список заданий cron ( crontab ). В результате задание cron пользователя не может быть запущено, так как для него требуются повышенные привилегии.
- Чтобы поместить задание cron в crontab текущего пользователя, введите
crontab -e - Чтобы поместить задание cron в тип crontab root
sudo crontab -e
Вторая причина - это пути, по порядку чтобы быть уверенным, что сценарий будет выполнен, пользователь должен добавить полный путь к сценарию, который будет выполняться в crontab. Другое решение - расширить переменную PATH для пользователей root, поместив следующую строку в верхней части их файла crontab:
PATH=/usr/sbin:/usr/bin:/sbin:/bin
, как упоминается в вики сообщества .
Вы можете прочитать ] вики сообщества о cron, поскольку она предоставляет дополнительную информацию о вышеупомянутом.
Согласно этому ответу , проблема кроется в расширении .sh. Удалите это (например, переименуйте ваш файл из rkhunter.sh в rkhunter.
Для подтверждения выполнения следующей команды run-parts --test /etc/cron.daily
Если ваш скрипт (rkhunter) включен в результаты, то все в порядке. Для получения дополнительной информации о команде run-parts читайте man-страницы man run-parts
В моей системе это произошло из-за того, что anacron не был установлен.
grep run-parts /etc/crontab
17 * * * * root cd / && run-parts --report /etc/cron.hourly
25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6 * * 7 root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6 1 * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )
Так что либо установите anacron, либо удалите тестовый -x / usr / sbin / anacron
Я думаю, что файлы с расширениями игнорируются.
запустите:
run-parts --test /etc/cron.daily
Если вы не видите свои скрипты в списке, удалите расширения .sh и повторите попытку.
Переименуйте ваш файл, чтобы он не имел .sh расширения
Чтобы проверить, в чем проблема, попробуйте
sudo run-parts --list /etc/cron.daily
и вы увидите, что его нет в списке. Так что запустите:
mv script.sh script
и попробуйте перечислить снова. Он должен быть в списке.
Мне не удалось запустить его с анакроном, я удалил анакрон из / etc / crontab и выполнил apt remove --purge anacron и сразу заработает.
Я не понимаю, зачем нам два планировщика.
Добавляя к ответу Стефа, вы также должны убедиться, что у них есть исполняемый бит:
$ ls -l
-rwxr-xr-x 1 root root 268 Jun 1 08:06 00logwatch
-rwxr-xr-x 1 root root 311 May 22 2012 0anacron
-rwxr-xr-x 1 root root 15007 Jun 6 14:08 apt
Вы должны иметь возможность запускать их, используя chmod + x filename .
Время выполнения ежедневных сценариев по умолчанию - 06 : 25 утра. Если ваша машина выключена в это время (каждый день), они не запускаются.
anacron запускает сценарии, которые были пропущены из-за того, что машина была выключена.
Вы можете настроить другое время, отредактировав / etc /crontab.
Такая же ситуация сегодня здесь
Я сделал
sudo journalctl -u cron -b | grep -i error
и обнаружил
cron[815]: Error: bad hour; while reading /etc/crontab
cron[815]: (*system*) ERROR (Syntax error, this crontab file will be ignored)
Я обнаружил, что кто-то (я !!!!) добавил строку, начинающуюся с
20 38 ...
и очевидно, что 38-й час не существует!
Похожая проблема решена этими шагами
Перезапустите службу cron, чтобы посмотреть, что произошло в логах.
service cron restartМониторинг журналов
grep -i cron /var/log/syslogshow
cron[37426]: (**) ERROR (Отсутствие новой строки перед EOF, этот файл crontab будет проигнорирован) cron[37426]: (CRON) INFO (Пропуск заданий @reboot - не запуск системы)
Журналы показывают, что неправильное поведение связано с EOF моего cron.
Попытка cat it cat /etc/cron.d/mycron доказывает, что в этом файле нет новой строки.
- Решение заключается в добавлении новой строки к последней строке.
echo >> /etc/cron.d/mycron
Если открыть файл с помощью Vim, затем сохранить (:wq), то он также добавит новую строку к последней строке файла.