cron.daily задания не работают

19

Я создал 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

#!/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 ofcourse своей электронной почтой.

Если я запускаю этот cronjob вручную, он работает нормально ./nameoffile.sh

Но это не работает ежедневно, в чем может быть причина или как я могу проверить это?

ударная волна
источник
2
Убедитесь, что файлы, которые вы создали в cron.daily / weekly / hourly / etc, являются исполняемыми, просто выполните
команду

Ответы:

6

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

Во-первых, это проблемы с разрешениями, то есть пользователь может запустить скрипт / команду, но демон cron не может, потому что задание находится в заданиях cron не того пользователя. Например, пользователь создает сценарий или запускает команду с повышенными привилегиями, т.е. использует sudo, а затем добавляет проверенный сценарий / команду в свой список заданий cron ( crontab). В результате задание пользователя cron не сможет быть запущено, так как оно требует повышенных привилегий.

  • Чтобы поместить задание cron в тип crontab текущего пользователя crontab -e
  • Чтобы поместить задание cron в тип crontab root sudo crontab -e

Вторая причина - пути, чтобы быть уверенным в том, что скрипт будет выполнен, пользователь должен добавить полный путь к скрипту, который будет выполняться в crontab. Другим решением было бы расширить переменную PATH корневых пользователей, поместив следующую строку вверху их файла crontab:

PATH=/usr/sbin:/usr/bin:/sbin:/bin

как вики сообщества упоминает .

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

Стеф К
источник
Так я просто поместил имя файла там?
sonicboom
Это на самом деле говорит, что для root нет предыдущей работы cron, и вы собираетесь написать свою первую, а затем она просит вас выбрать редактор для изменения crontab. Просто выберите один из меню (1.bin / ed, и т. Д.). Выбрать нано легко, просто обратите внимание на инструкции.
Stef K
Таким образом, чтобы запускаться один раз в день в 10 вечера, я бы поставил * 22 * ​​* * test> rkhunter.sh, верно?
sonicboom
ах классно! попробую прямо сейчас!
sonicboom
Для чего нужен тест> rkhunter.sh?
sonicboom
76

Согласно этому ответу, проблема заключается в расширении .sh. Удалите это (например, переименуйте ваш файл из rkhunter.sh в rkhunter.

Для подтверждения выполните следующую команду run-parts --test /etc/cron.daily

Если ваш скрипт (rkhunter) включен в результаты, все хорошо. Для получения дополнительной информации о команде run-parts прочитайте справочные страницы по нейman run-parts

user19366
источник
1
Это ответ, который я искал, после различных тестов я понял, что выполняется другой файл сценария без расширения sh
Альберт Катала
5
как сказал @rharriso в своем ответе. это не столько проблема с «.sh», сколько проблема с «.». любой файл с любым расширением будет пропущен. цитировать слова непосредственно из слов man run-parts«имена должны состоять исключительно из прописных и строчных букв ASCII, цифр ASCII, подчеркиваний ASCII и минус-дефисов ASCII»
Northern-Bradley
11

В моей системе это было потому, что анакрон не был установлен.

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

Natim
источник
1
+1 По умолчанию анакрон не установлен? Я бы ожидал этого. Я думаю, что это решило бы это для меня. Благодарю.
Лепе
Конечно же, это не было на моем ... FFS, я уверен, что это было, как сценарий выполнялся несколько месяцев назад !: dpkg --get-selections | grep cron.. <ругается>
Grizly
Да, я тоже не знаю, что произошло, поскольку этот пакет обычно устанавливается при запуске.
Натим
10
Это не совсем правильно. anacronне обязательно; ||оператор в кронтабе команды запускает , run-partsкогда Anacron НЕ установлен. Когда anacronустановлено, это делает эти ежедневные / еженедельные / ежемесячные run-partsкоманды избыточными.
TalkLittle
Так что, может быть, это потому, что не работали части запуска? В любом случае установка анакрона исправила это для меня.
Натим
10

Я думаю, что файлы с расширениями игнорируются.

бегать:

 run-parts --test /etc/cron.daily

Если вы не видите свои скрипты в списке, удалите расширения .sh и попробуйте снова.

rharriso
источник
5

Добавляя к ответу Stef, вы также должны убедиться, что они имеют исполняемый бит:

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

Braiam
источник
Какие это файлы? это содержимое папки /etc/logrotate.d?
Realtebo
4

Переименуйте ваш файл, чтобы не иметь расширение .sh

Чтобы убедиться, что это проблема, попробуйте

sudo run-parts --list /etc/cron.daily 

вы увидите, что его нет в списке. Итак, бегите:

mv script.sh script

и попробуйте еще раз. Это должно быть в списке.

Элан Кивити
источник
Эта проблема, кажется, влияет на любой исполняемый файл, который имеет расширение. У меня был файл с именем «filename.ca», и он также не
отображал
0

Я не мог запустить его с анакроном, я удалил анакрон из /etc/crontab и выполнил, apt remove --purge anacronи он работает сразу же.

Я не понимаю, зачем нам два планировщика.

Патрик Ласло
источник
0

Та же ситуация сегодня здесь

я сделал

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-го часа не существует!

realtebo
источник