lavori cron.daily non in esecuzione


19

Ho creato 3 lavori cron giornalieri da eseguire.

Di seguito sono riportati i tre posizionati in 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

Ho sostituito me@email.com ofcourse con la mia email.

Se eseguo questo cronjob manualmente funziona benissimo ./nameoffile.sh

Ma non funziona quotidianamente, quale può essere la causa o come posso verificare questo?


2
Assicurati che i file che hai creato in cron.daily / settimanali / orari / etc siano eseguibili, basta fare un chmod + x /etc/cron.daily/whatever
Turgut Kalfaoglu

Risposte:


6

Esistono due possibili sospetti che di solito cronimpediscono l'esecuzione di lavori.

Il primo sono i problemi di autorizzazione, ovvero un utente può eseguire lo script / comando ma il demone cron non può perché il lavoro si trova nei lavori cron dell'utente sbagliato. Ad esempio, l'utente crea uno script o esegue un comando con privilegi elevati, ad esempio utilizzando sudo, quindi aggiunge lo script / il comando testato al suo elenco di cron job ( crontab). Il risultato è che il cron job dell'utente non sarà in grado di essere eseguito poiché necessita di privilegi elevati.

  • Per inserire un lavoro cron nel tipo crontab dell'utente corrente crontab -e
  • Per mettere un cron job nel tipo crontab di root sudo crontab -e

Il secondo motivo sono i percorsi, per essere sicuri che lo script verrà eseguito, l'utente deve aggiungere l'intero percorso allo script per essere eseguito in crontab. Un'altra soluzione sarebbe quella di espandere la variabile PATH degli utenti root posizionando la seguente riga nella parte superiore del loro file crontab:

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

come menziona la wiki della community .

Potresti voler leggere la wiki della community su cron in quanto fornisce ulteriori dettagli su quanto sopra.


Quindi devo solo inserire il nome del file?
sonicboom,

In realtà sta dicendo che non esiste un cron job precedente per root e che stai per scrivere il tuo primo e poi ti chiede di scegliere un editor per modificare il crontab. Basta sceglierne uno dal menu (1.bin / ed, ecc.). Scegli nano è facile, basta prestare attenzione alle istruzioni.
Stef K,

Quindi per eseguire una volta al giorno alle 22:00 metterei * 22 * ​​* * test> rkhunter.sh giusto?
sonicboom,

ah fantastico! proverò subito!
sonicboom,

A cosa serve il test> rkhunter.sh?
sonicboom,

76

Secondo questa risposta, il problema risiede con l'estensione .sh. Rimuovilo (ad esempio, rinomina il tuo file da rkhunter.sh a rkhunter.

Per confermare eseguire il comando seguente run-parts --test /etc/cron.daily

Se il tuo script (rkhunter) è incluso nei risultati, tutto va bene. Per ulteriori informazioni sul comando run-parts, leggere le pagine man su di essoman run-parts


1
Questa è la risposta che stavo cercando, dopo vari test, mi sono reso conto che viene eseguito un altro file di script senza estensione sh
Albert Català,

5
come ha detto @rharriso nella sua risposta. non è tanto un problema con ".sh" quanto un problema con ".". ci mancherà qualsiasi file con qualsiasi estensione. per citare direttamente da man run-parts"i nomi devono essere interamente composti da lettere maiuscole e minuscole ASCII, cifre ASCII, caratteri di sottolineatura ASCII e meno trattini ASCII"
Northern-Brady

11

Nel mio sistema era perché anacron non era installato.

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 )

Quindi installa anacron o rimuovi il test -x / usr / sbin / anacron


1
+1 Anacron non è installato di default? Me lo sarei aspettato. Penso che lo risolverebbe per me. Grazie.
lepe

Abbastanza sicuro, non era lì sul mio .. FFS, sono sicuro che lo fosse, dato che la sceneggiatura era in esecuzione qualche mese fa !: dpkg --get-selections | grep cron.. <
swears

Sì, non so nemmeno cosa sia successo poiché si tratta di un pacchetto solitamente installato all'avvio.
Natim,

10
Questo non è proprio corretto. anacronnon è necessario; l' ||operatore nei comandi crontab viene eseguito run-partsquando anacron NON è installato. Quando anacronè installato, rende run-partssuperflui quei comandi giornalieri / settimanali / mensili .
TalkLittle

Quindi forse è stato perché le parti di scorrimento non funzionavano? In ogni caso l'installazione di Anacron l'ha risolto per me.
Natim

10

Penso che i file con estensioni vengano ignorati.

correre:

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

Se non vedi gli script elencati, rimuovi le estensioni .sh e riprova.


5

Aggiungendo alla risposta Stef, dovresti anche assicurarti che abbiano il bit eseguibile:

$ 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

Dovresti essere in grado di eseguirli utilizzando chmod +x filename.


Quali file sono questi? è il contenuto della cartella /etc/logrotate.d?
realtebo

4

Rinomina il tuo file per non avere l'estensione .sh

Per verificare questo è il problema, provare

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

vedrai che non è elencato. Quindi corri:

mv script.sh script

e riprova ad elencare. Dovrebbe essere elencato.


Questo problema sembra influenzare qualsiasi eseguibile che ha un'estensione. Avevo un nome di file "nomefile.ca" e non lo avrei elencato fino a quando non l'ho rinominato "nomefile"
kiwicomb123

0

Non sono riuscito a farlo funzionare con Anacron, ho rimosso Anacron /etc/crontabed eseguito apt remove --purge anacrone funziona immediatamente.

Non capisco perché abbiamo bisogno di due scheduler.


0

Stessa situazione oggi qui

L'ho fatto

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

e trovato

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

Ho scoperto che qualcuno (io !!!!) ha aggiunto una riga a partire da

20 38 ...

e ovviamente la 38a ora non esiste!

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.