Zadania cron.daily nie są uruchomione


19

Stworzyłem 3 codzienne zadania crona do uruchomienia.

Poniżej znajdują się trzy, które są umieszczone w 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

Mój adres e-mail.com oczywiście zastąpiłem moim adresem e-mail.

Jeśli uruchomię tę cronjob ręcznie, działa to dobrze ./nameoffile.sh

Ale to nie działa codziennie, co może być przyczyną lub w jaki sposób mogę to sprawdzić?


2
Upewnij się, że pliki utworzone w cron.daily / weekly / hourly / etc są wykonywalne, po prostu wykonaj chmod + x
/etc/cron.daily/whokolwiek

Odpowiedzi:


6

Możliwe są dwa podejrzane, które zwykle powodują, że cronzadania nie mogą zostać uruchomione.

Pierwszym z nich są problemy z uprawnieniami, tzn. Użytkownik może uruchomić skrypt / polecenie, ale demon cron nie może, ponieważ zadanie jest w zadaniach crona niewłaściwego użytkownika. Na przykład użytkownik tworzy skrypt lub uruchamia polecenie z podwyższonymi uprawnieniami, tj. Używa sudo, a następnie dodaje przetestowany skrypt / polecenie do swojej listy zadań cron ( crontab). Powoduje to, że zadanie cron użytkownika nie będzie mogło zostać uruchomione, ponieważ wymaga podwyższonych uprawnień.

  • Aby umieścić zadanie cron w typie crontab bieżącego użytkownika crontab -e
  • Aby umieścić zadanie cron w typie crontab roota sudo crontab -e

Drugi powód to ścieżki, aby mieć pewność, że skrypt zostanie wykonany, użytkownik musi dodać pełną ścieżkę do skryptu, który ma zostać wykonany w crontab. Innym rozwiązaniem byłoby rozszerzenie zmiennej PATH dla użytkowników root poprzez umieszczenie następującego wiersza u góry pliku crontab:

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

jak wspomina wiki społeczności .

Możesz przeczytać wiki społeczności o cronie, ponieważ zawiera ono dalsze szczegóły na temat powyższego.


Więc czy mogę tam po prostu podać nazwę pliku?
sonicboom

To tak naprawdę mówi, że nie ma wcześniejszej pracy crona dla roota, a ty napiszesz swoją pierwszą, a następnie poprosi cię o wybranie edytora w celu zmodyfikowania pliku crontab. Wystarczy wybrać jeden z menu (1.bin / ed itp.). Wybierz nano to łatwe, po prostu zwróć uwagę na instrukcje.
Stef K

Więc aby uruchamiać raz dziennie o 22:00, postawiłbym * 22 * ​​* * test> rkhunter.sh, prawda?
sonicboom

ah super! źle spróbuj teraz!
sonicboom

Do czego służy test> rkhunter.sh?
sonicboom

76

Zgodnie z odpowiedzią problem leży w rozszerzeniu .sh. Usuń to (więc na przykład zmień nazwę pliku z rkhunter.sh na rkhunter.

Aby potwierdzić, uruchom następujące polecenie run-parts --test /etc/cron.daily

Jeśli twój skrypt (rkhunter) znajduje się w wynikach, wszystko jest w porządku. Aby uzyskać więcej informacji na temat polecenia run-parts, przeczytaj znajdujące się na nim strony podręcznika manman run-parts


1
Oto odpowiedź, której szukałem, po różnych testach zdałem sobie sprawę, że wykonywany jest inny plik skryptu bez rozszerzenia sh
Albert Català

5
jak powiedział @rharriso w swojej odpowiedzi. to nie tyle problem z „.sh”, co problem z „.”. każdy plik z dowolnym rozszerzeniem zostanie pominięty. cytować bezpośrednio z man run-parts„nazwy muszą składać się wyłącznie z wielkich i małych liter ASCII, cyfr ASCII, znaków podkreślenia ASCII i znaków minus ASCII”
północny bradley

11

W moim systemie było tak dlatego, że anacron nie został zainstalowany.

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 )

Więc zainstaluj anacron lub usuń test -x / usr / sbin / anacron


1
+1 Czy anacron nie jest domyślnie zainstalowany? Oczekiwałbym tego. Myślę, że to by mnie rozwiązało. Dzięki.
lepe

Rzeczywiście, nie było go u mnie .. FFS, jestem pewien, że tak, ponieważ skrypt był wykonywany kilka miesięcy temu !: dpkg --get-selections | grep cron.. <
swears

Tak, nie wiem, co się stało, ponieważ jest to pakiet zwykle instalowany podczas uruchamiania.
Natim

10
To nie jest tak naprawdę poprawne. anacronnie jest konieczne; ||operator w crontab komendy uruchamiają run-partsgdy anacron nie jest zainstalowany. Po anacronzainstalowaniu powoduje, że te codzienne / tygodniowe / miesięczne run-partspolecenia stają się zbędne.
TalkLittle

Więc może dlatego, że części działające nie działały? W anycase instalacja anacrona naprawiła to dla mnie.
Natim

10

Myślę, że pliki z rozszerzeniami są ignorowane.

biegać:

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

Jeśli nie widzisz swoich skryptów na liście, usuń rozszerzenia .sh i spróbuj ponownie.


5

Dodając do odpowiedzi Stef, powinieneś również upewnić się, że mają one plik wykonywalny:

$ 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

Powinieneś być w stanie uruchomić je za pomocą chmod +x filename.


Jakie to są pliki? czy jest to zawartość folderu /etc/logrotate.d?
realtebo

4

Zmień nazwę pliku, aby nie miał rozszerzenia .sh

Aby sprawdzić, czy to jest problem, spróbuj

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

zobaczysz, że nie ma go na liście. Więc uruchom:

mv script.sh script

i spróbuj jeszcze raz. Powinien być wymieniony.


Problemy te wydają się wpływać na każdy plik wykonywalny, który ma rozszerzenie. Miałem nazwy plików „nazwa_pliku.ca”, a także nie wyświetlałbym go, dopóki nie
zmieniłem

0

Nie mogłem uruchomić go z anakronem, usunąłem anakron /etc/crontabi wykonałem apt remove --purge anacrongo i działa od razu.

Nie rozumiem, dlaczego potrzebujemy dwóch harmonogramów.


0

Ta sama sytuacja dzisiaj tutaj

Zrobiłem

sudo journalctl -u cron -b | grep -i error

i znalezione

cron[815]: Error: bad hour; while reading /etc/crontab
cron[815]: (*system*) ERROR (Syntax error, this crontab file will be ignored)

Odkryłem, że ktoś (ja !!!!) dodał wiersz zaczynający się od

20 38 ...

i oczywiście 38. godzina nie istnieje!

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.