Perché gli script di crontab non funzionano?

Ambiente diverso

Cron trasmette un set minimo di variabili di ambiente ai tuoi lavori. Per vedere la differenza, aggiungi un lavoro fittizio come questo:

* * * * * env > /tmp/env.output

Attendi la creazione di /tmp/env.output , quindi rimuovi il lavoro. Ora confronta il contenuto di /tmp/env.output con l'output di env eseguito nel tuo terminale normale.

Un "getcha" comune qui è la variabile di ambiente PATH che è diversa. Forse lo script di cron utilizza il comando somecommand trovato in /opt/someApp/bin , che hai aggiunto a PATH in /etc/environment ? cron ignora PATH da quel file, quindi runnning somecommand dallo script fallirà quando viene eseguito con cron, ma funziona quando viene eseguito in un terminale. Vale la pena notare che le variabili da /etc/environment verranno passate ai lavori cron, ma non solo le variabili cron si impostano in modo specifico, come PATH .

Per aggirare questo problema, imposta la tua variabile PATH nella parte superiore dello script. Per es.

#!/bin/bash
PATH=/opt/someApp/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

# rest of script follows

Alcuni preferiscono usare solo i percorsi assoluti per tutti i comandi. Raccomando contro quello. Considera cosa succede se vuoi eseguire il tuo script su un sistema diverso, e su quel sistema, invece, il comando è in /opt/someAppv2.2/bin . Dovresti passare attraverso l'intero script sostituendo /opt/someApp/bin con /opt/someAppv2.2/bin invece di fare solo una piccola modifica sulla prima riga dello script.

Puoi anche impostare la variabile PATH nel file crontab, che si applicherà a tutti i lavori cron. Per es.

PATH=/opt/someApp/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

15 1 * * * backupscript --incremental /home /root

Il mio trucchetto in alto: se dimentichi di aggiungere una nuova riga alla fine del file crontab . In altre parole, il file crontab dovrebbe terminare con una riga vuota.

Di seguito è riportata la sezione pertinente nelle pagine man per questo problema ( man crontab e poi salta alla fine):

   Although cron requires that each entry in a crontab end  in  a  newline
   character,  neither the crontab command nor the cron daemon will detect
   this error. Instead, the crontab will appear to load normally. However,
   the  command  will  never  run.  The best choice is to ensure that your
   crontab has a blank line at the end.

   4th Berkeley Distribution      29 December 1993               CRONTAB(1)

Il daemon cron non è in esecuzione. Ho davvero sbagliato con questo alcuni mesi fa.

Tipo:

pgrep cron 

Se non vedi alcun numero, cron non è in esecuzione. sudo /etc/init.d/cron start può essere usato per avviare cron.

EDIT: Invece di invocare gli script di init tramite /etc/init.d, usa il servizio utility, ad es.

sudo service cron start

I nomi di file di script in cron.d/ , cron.daily/ , cron.hourly/ , ecc. non dovrebbero contenere punto ( . ), altrimenti le parti di esecuzione salteranno loro.

Vedi run-parts (8):

   If neither the --lsbsysinit option nor the --regex option is given then
   the names must consist entirely of upper and lower case  letters,  dig‐
   its, underscores, and hyphens.

   If  the  --lsbsysinit  option  is given, then the names must not end in
   .dpkg-old  or .dpkg-dist or .dpkg-new or .dpkg-tmp, and must belong  to
   one  or more of the following namespaces: the LANANA-assigned namespace
   (^[a-z0-9]+$);   the   LSB   hierarchical   and   reserved   namespaces
   (^_?([a-z0-9_.]+-)+[a-z0-9]+$);  and  the  Debian cron script namespace
   (^[a-zA-Z0-9_-]+$).

Quindi, se hai uno script cron backup.sh , analyze-logs.pl in cron.daily/ directory, è meglio rimuovere i nomi delle estensioni.

In molti ambienti cron esegue i comandi usando sh , mentre molte persone presumono che userà bash .

Suggerimenti per testare o correggere questo errore per un comando fallito:

• Prova a eseguire il comando in sh per vedere se funziona
• Avvia il comando in una subshell bash per assicurarti che venga eseguito in bash:
  bash -c "mybashcommand"
• Chiedi a cron di eseguire tutti i comandi in bash impostando la shell nella parte superiore di crontab:
  SHELL=/bin/bash
• Se il comando è uno script, assicurati che lo script contenga uno shebang:
  #!/bin/bash

Ho avuto alcuni problemi con i fusi orari. Cron era in esecuzione con il nuovo fuso orario dell'installazione. La soluzione era riavviare cron:

sudo service cron restart

Se il comando crontab contiene un simbolo % , cron cerca di interpretarlo. Quindi se stai usando un comando con % in esso (come una specifica di formato per il comando date) dovrai fuggire.

Questo e altri trucchi buoni qui:
link

Il percorso assoluto dovrebbe essere usato per gli script:

Ad esempio, è necessario utilizzare /bin/grep anziché grep :

# m h  dom mon dow   command
0 0 *  *  *  /bin/grep ERROR /home/adam/run.log &> /tmp/errors

Invece di:

# m h  dom mon dow   command
0 0 *  *  *  grep ERROR /home/adam/run.log &> /tmp/errors

Questo è particolarmente complicato, perché lo stesso comando funzionerà quando viene eseguito dalla shell. Il motivo è che cron non ha la stessa variabile di ambiente PATH dell'utente.

È anche possibile che la password dell'utente sia scaduta. Anche la password di root può scadere. Puoi tail -f /var/log/cron.log e vedrai cron fall con password scaduta. Puoi impostare la password in modo che non scada mai: passwd -x -1 <username>

In alcuni sistemi (Debian, Ubuntu) la registrazione di cron non è abilitata di default. In /etc/rsyslog.conf o /etc/rsyslog.d/50-default.conf la riga:

# cron.*                          /var/log/cron.log

dovrebbe essere modificato ( sudo nano /etc/rsyslog.conf ) non commentato per:

cron.*                          /var/log/cron.log

Dopodiché, devi riavviare rsyslog tramite

/etc/init.d/rsyslog restart

o

service rsyslog restart 

Fonte: Abilita la registrazione crontab in Debian Linux

In alcuni sistemi (Ubuntu) il file di registrazione separato per cron non è abilitato di default, ma i registri relativi a cron vengono visualizzati nel file syslog. Si può usare

cat /var/log/syslog | grep cron

per visualizzare i messaggi relativi ai cron.

Cron sta chiamando uno script che non è eseguibile.

Eseguendo chmod +x /path/to/scrip lo script diventa eseguibile e dovrebbe risolvere questo problema.

Se il cronjob richiama le app della GUI, devi dire loro che cosa dovrebbero usare DISPLAY.

Esempio: avvio di Firefox con cron.

Lo script dovrebbe contenere export DISPLAY=:0 da qualche parte.

I problemi di autorizzazione sono abbastanza comuni, temo.

Si noti che una soluzione comune è quella di eseguire tutto usando crontab di root, che a volte è un'idea davvero cattiva. Impostare le autorizzazioni appropriate è sicuramente un problema ampiamente trascurato.

Autorizzazione della tabella cron non sicura

Una tabella cron è rifiutata se la sua autorizzazione non è sicura

sudo service cron restart
grep -i cron /var/log/syslog|tail -2
2013-02-05T03:47:49.283841+01:00 ubuntu cron[49906]: (user) INSECURE MODE (mode 0600 expected) (crontabs/user)

Il problema è risolto con

# correct permission
sudo chmod 600 /var/spool/cron/crontabs/user
# signal crond to reload the file
sudo touch /var/spool/cron/crontabs

Lo script è sensibile alla posizione. Questo è legato al fatto di usare sempre percorsi assoluti in uno script, ma non esattamente lo stesso. Il tuo lavoro cron potrebbe aver bisogno di cd in una directory specifica prima di essere eseguito, ad es. potrebbe essere necessario un task rake su un'applicazione Rails nella root dell'applicazione per Rake per trovare l'attività corretta, per non parlare della configurazione del database appropriata, ecc.

Quindi una voce crontab di

23 3 * * * /usr/bin/rake db:session_purge RAILS_ENV=production

sarebbe meglio come

23 3 * * * cd /var/www/production/current && /usr/bin/rake db:session_purge RAILS_ENV=production

Oppure, per mantenere la voce crontab più semplice e meno fragile:

23 3 * * * /home/<user>/scripts/session-purge.sh

con il seguente codice in /home/<user>/scripts/session-purge.sh :

cd /var/www/production/current
/usr/bin/rake db:session_purge RAILS_ENV=production

Le specifiche di Crontab che hanno funzionato nel passato possono interrompersi quando vengono spostate da un file crontab a un altro. A volte il motivo è che hai spostato le specifiche da un file crontab di sistema a un file crontab utente o viceversa.

Il formato di specifica del job cron varia tra i file crontab degli utenti (/ var / spool / cron / username o / var / spool / cron / crontabs / username) e il sistema crontabs ( /etc/crontab e i file in /etc/cron.d ).

Il sistema crontabs ha un campo aggiuntivo 'utente' proprio prima del comando da eseguire.

Ciò causerà errori che indicano cose come george; command not found quando sposti un comando da /etc/crontab o un file in /etc/cron.d nel file crontab di un utente.

Al contrario, cron invierà errori come /usr/bin/restartxyz is not a valid username o simili quando si verifica il contrario.

lo script cron sta invocando un comando con l'opzione --verbose

Ho avuto uno script cron non riuscito su di me perché ero in autopilot mentre scrivevo lo script e ho incluso l'opzione --verbose:

#!/bin/bash
some commands
tar cvfz /my/archive/file.tar.gz /my/shared/directory
come more commands

Lo script ha funzionato bene quando è stato eseguito dalla shell, ma non è riuscito quando è in esecuzione da crontab perché l'output dettagliato passa a stdout quando viene eseguito dalla shell, ma da nessuna parte quando viene eseguito da crontab. Facile soluzione per rimuovere la "v":

#!/bin/bash
some commands
tar cfz /my/archive/file.tar.gz /my/shared/directory
some more commands

Il motivo più frequente che ho visto cron fallire in un programma indicato in modo errato. Ci vuole pratica per specificare un lavoro pianificato per 11:15 pm come 30 23 * * * invece di * * 11 15 * o 11 15 * * * . Il giorno della settimana per i lavori dopo la mezzanotte si confonde anche M-F è 2-6 dopo la mezzanotte non 1-5 . Le date specifiche sono di solito un problema poiché li utilizziamo raramente * * 3 1 * non è il 3 marzo.

Se il tuo lavoro con piattaforme diverse che utilizzano opzioni non supportate come 2/3 nelle specifiche temporali può anche causare guasti. Questa è un'opzione molto utile ma non universalmente disponibile. Ho anche riscontrato problemi con elenchi come 1-5 o 1,3,5 .

Anche l'utilizzo di percorsi non qualificati ha causato problemi. Il percorso predefinito è in genere /bin:/usr/bin , quindi verranno eseguiti solo i comandi standard. Queste directory di solito non hanno il comando desiderato. Ciò influisce anche sugli script che utilizzano comandi non standard. Altre variabili di ambiente possono anche mancare.

Clobare un crontab esistente mi ha causato problemi. Ora carico da una copia di file. Questo può essere recuperato dal crontab esistente usando crontab -l se viene danneggiato. Conservo la copia di crontab in ~ / bin. Viene commentato in tutto e termina con la riga # EOF . Questo viene ricaricato ogni giorno da una voce crontab come:

#!/usr/bin/crontab
# Reload this crontab
#
54 12    *   *   *   ${HOME}/bin/crontab

Il comando di ricaricamento sopra si basa su un crontab eseguibile con un percorso bang che esegue crontab. Alcuni sistemi richiedono l'esecuzione di crontab nel comando e la specifica del file. Se la directory è condivisa in rete, spesso utilizzo crontab.$(hostname) come nome del file. Questo alla fine correggerà i casi in cui il crontab sbagliato viene caricato sul server sbagliato.

L'utilizzo del file fornisce un backup di ciò che dovrebbe essere il crontab e consente di eseguire automaticamente il backup delle modifiche temporanee (l'unica volta che utilizzo crontab -e ). Sono disponibili intestazioni che aiutano a ottenere i parametri di pianificazione corretti. Li ho aggiunti quando gli utenti inesperti avrebbero modificato un crontab.

Raramente, ho eseguito comandi che richiedono l'input dell'utente. Questi falliscono sotto crontab, anche se alcuni funzioneranno con il reindirizzamento dell'input.

Se accedi a un account tramite chiavi SSH è possibile accedere all'account ma non notare che la password dell'account è bloccata (ad es. a causa di tentativi di password scaduti o non validi)

Se il sistema utilizza PAM e l'account è bloccato, questo può impedire l'esecuzione del cronjob. (L'ho provato su Solaris, ma non su Ubuntu)

Potresti trovare messaggi come questo in / var / adm / messages:

Oct 24 07:51:00 mybox cron[29024]: [ID 731128 auth.notice] pam_unix_account: cron attempting to validate locked account myuser from local host
Oct 24 07:52:00 mybox cron[29063]: [ID 731128 auth.notice] pam_unix_account: cron attempting to validate locked account myuser from local host
Oct 24 07:53:00 mybox cron[29098]: [ID 731128 auth.notice] pam_unix_account: cron attempting to validate locked account myuser from local host
Oct 24 07:54:00 mybox cron[29527]: [ID 731128 auth.notice] pam_unix_account: cron attempting to validate locked account myuser from local host

Tutto ciò che dovresti fare è eseguire:

# passwd -u <USERNAME>

come root per sbloccare l'account, e il crontab dovrebbe funzionare di nuovo.

Se hai un comando come questo:

* * * * * /path/to/script >> /tmp/output

e non funziona e non puoi vedere alcun output, non significa necessariamente che cron non funziona. Lo script potrebbe essere interrotto e l'output andrà a stderr che non viene passato a / tmp / output. Verifica che questo non sia il caso, catturando anche questo output:

* * * * * /path/to/script >> /tmp/output 2>&1

per vedere se questo ti aiuta a cogliere il problema.

=== Avviso Docker ===

Se utilizzi la finestra mobile,

Penso sia corretto aggiungere che non sono riuscito a far eseguire cron in background.

Per eseguire un processo cron all'interno del contenitore, ho utilizzato il supervisore e ho eseguito cron -f , insieme con l'altro processo.

Modifica: un altro problema: anche io non sono riuscito a farlo funzionare durante l'esecuzione del contenitore con reti HOST. Vedi questo problema anche qui: link

Nel mio caso, cron e crontab avevano proprietari diversi.

NON funziona Ho avuto questo:

[email protected] ~ $ ps -ef | grep cron | grep -v grep
User    2940    7284 pty1     19:58:41 /usr/bin/crontab
SYSTEM   11292     636 ?        22:14:15 /usr/sbin/cro 

Fondamentalmente dovevo eseguire cron-config e rispondere correttamente alle domande. C'è un punto in cui mi è stato richiesto di inserire la mia password utente Win7 per il mio account "Utente". Dalla lettura che ho fatto, sembra che questo sia un potenziale problema di sicurezza, ma io sono l'unico amministratore su una singola rete domestica, quindi ho deciso che era OK.

Ecco la sequenza di comandi che mi ha permesso di andare:

[email protected] ~ $ cron-config
The cron daemon can run as a service or as a job. The latter is not recommended.
Cron is already installed as a service under account LocalSystem.
Do you want to remove or reinstall it? (yes/no) yes
OK. The cron service was removed.

Do you want to install the cron daemon as a service? (yes/no) yes
Enter the value of CYGWIN for the daemon: [ ] ntsec

You must decide under what account the cron daemon will run.
If you are the only user on this machine, the daemon can run as yourself.
   This gives access to all network drives but only allows you as user.
To run multiple users, cron must change user context without knowing
  the passwords. There are three methods to do that, as explained in
  http://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-nopasswd1
If all the cron users have executed "passwd -R" (see man passwd),
  which provides access to network drives, or if you are using the
  cyglsa package, then cron should run under the local system account.
Otherwise you need to have or to create a privileged account.
  This script will help you do so.
Do you want the cron daemon to run as yourself? (yes/no) no

Were the passwords of all cron users saved with "passwd -R", or
are you using the cyglsa package ? (yes/no) no

Finding or creating a privileged user.
The following accounts were found: 'cyg_server' .
This script plans to use account cyg_server.
Do you want to use another privileged account name? (yes/no) yes
Enter the other name: User

Reenter: User


Account User already exists. Checking its privileges.
INFO: User is a valid privileged account.
INFO: The cygwin user name for account User is User.

Please enter the password for user 'User':
Reenter:
Running cron_diagnose ...
... no problem found.

Do you want to start the cron daemon as a service now? (yes/no) yes
OK. The cron daemon is now running.

In case of problem, examine the log file for cron,
/var/log/cron.log, and the Windows event log (using /usr/bin/cronevents)
for information about the problem cron is having.

Examine also any cron.log file in the HOME directory
(or the file specified in MAILTO) and cron related files in /tmp.

If you cannot fix the problem, then report it to [email protected]
Please run the script /usr/bin/cronbug and ATTACH its output
(the file cronbug.txt) to your e-mail.

WARNING: PATH may be set differently under cron than in interactive shells.
         Names such as "find" and "date" may refer to Windows programs.


[email protected] ~ $ ps -ef | grep cron | grep -v grep
    User    2944   11780 ?        03:31:10 /usr/sbin/cron
    User    2940    7284 pty1     19:58:41 /usr/bin/crontab

[email protected] ~ $

Stavo scrivendo uno script di installazione shell che crea un altro script per eliminare i vecchi dati di transazione da un database. Come parte dell'attività, è stato necessario configurare quotidianamente il cron processo da eseguire a un'ora arbitraria, quando il carico del database era basso.

Ho creato un file mycronjob con cron schedule, username & amp; il comando e copiato nella directory /etc/cron.d . I miei due trucchi:

1. Il file mycronjob doveva essere di proprietà di root per eseguire
2. Ho dovuto impostare i permessi del file su 644 - 664 non funzionanti.

Un problema di autorizzazione apparirà in /var/log/syslog come qualcosa di simile a:

Apr 24 18:30:01 ip-11-22-33-44 cron[40980]: (*system*) INSECURE MODE (group/other writable) (/etc/crontab)
Apr 24 18:30:01 ip-11-22-33-44 cron[40980]: (*system*) INSECURE MODE (group/other writable) (/etc/cron.d/user)

La prima riga si riferisce al file /etc/crontab e la successiva a un file che ho inserito in /etc/cront.d .

Linea scritta in un modo in cui crontab non capisce. Deve essere scritto correttamente. Ecco CrontabHowTo .

Il daemon Cron potrebbe essere in esecuzione, ma in realtà non funziona. Prova a riavviare cron:

sudo /etc/init.d/cron restart

Scrittura su cron tramite "crontab -e" con l'argomento username in una riga. Ho visto esempi di utenti (o amministratori di sistema) che scrivono i loro script di shell e non capiscono perché non si automatizzano. L'argomento "utente" esiste in / etc / crontab, ma non nei file definiti dall'utente. quindi, ad esempio, il tuo file personale sarebbe qualcosa del tipo:

# m h dom mon dow command

* * */2  *   *  /some/shell/script

mentre / etc / crontab sarebbe:

# m h dom mon dow user   command

* * */2  *   *  jdoe   /some/shell/script

Quindi, perché dovresti fare quest'ultimo? Beh, a seconda di come si vogliono impostare i permessi, questo può diventare molto contorto. Ho scritto degli script per automatizzare le attività per gli utenti che non capiscono le complessità o che non vogliono preoccuparsi del lavoro ingrato. Impostando le autorizzazioni su --x------ , posso rendere eseguibile lo script senza che sia in grado di leggere (e forse accidentalmente modificarlo). Tuttavia, potrei voler eseguire questo comando con molti altri da un file (rendendo così più semplice la manutenzione), ma assicurati che l'output del file sia assegnato al proprietario giusto. Così facendo (almeno in Ubuntu 10.10) si rompono sia l'impossibilità di leggere il file che l'esecuzione, oltre al problema menzionato prima con l'inserimento di periodi in / etc / crontab (che, stranamente, non causa errori quando si passa attraverso crontab -e ).

Ad esempio, ho visto casi di sudo crontab -e usati per eseguire uno script con permessi di root, con un chown username file_output corrispondente nello script della shell. Sciatto, ma funziona. IMHO, L'opzione più elegante è quella di metterlo in /etc/crontab con il nome utente dichiarato e le autorizzazioni appropriate, quindi file_output va nel posto giusto e proprietario.

Sviluppando ciò che Aaron Peart ha menzionato sulla modalità dettagliata, a volte gli script non in modalità dettagliata verranno inizializzati ma non terminati se il comportamento predefinito di un comando incluso è quello di generare una riga o più sullo schermo una volta avviato il processo. Ad esempio, ho scritto uno script di backup per la nostra intranet che utilizza curl, un'utilità che scarica o carica file su server remoti, ed è abbastanza utile se si può accedere solo a detti file remoti tramite HTTP. L'uso del "curl collegamento " causava uno script che ho scritto per appendere e non completare mai perché sputa una nuova riga seguita da una linea di progresso. Ho dovuto usare il flag silenzioso (-s) per dirgli di non produrre alcuna informazione, e scrivere nel mio codice da gestire se il file non è riuscito a scaricare.

Sebbene sia possibile definire variabili di ambiente nel crontable, non si è in uno script di shell. Quindi le costruzioni come le seguenti non funzioneranno:

SOME_DIR=/var/log
MY_LOG_FILE=${SOME_LOG}/some_file.log

BIN_DIR=/usr/local/bin
MY_EXE=${BIN_DIR}/some_executable_file

0 10 * * * ${MY_EXE} some_param >> ${MY_LOG_FILE}

Questo perché le variabili non sono interpretate nel crontable: tutti i valori sono presi letteralmente. E questo è lo stesso se si omettono le parentesi. Quindi i tuoi comandi non verranno eseguiti e i tuoi file di registro non verranno scritti ...

Devi invece definire tutte le variabili d'ambiente direttamente:

SOME_DIR=/var/log
MY_LOG_FILE=/var/log/some_file.log

BIN_DIR=/usr/local/bin
MY_EXE=/usr/local/bin/some_executable_file

0 10 * * * ${MY_EXE} some_param >> ${MY_LOG_FILE}

Quando un'attività viene eseguita in cron, stdin è chiuso. I programmi che si comportano in modo diverso a seconda che lo stdin sia disponibile o meno si comportano in modo diverso tra la sessione della shell e in cron.

Un esempio è il programma goaccess per l'analisi dei file di log del server web. Questo NON funziona in cron:

goaccess -a -f /var/log/nginx/access.log > output.html

e goaccess mostra la pagina di aiuto invece di creare il rapporto. Nella shell questo può essere riprodotto con

goaccess -a -f /var/log/nginx/access.log > output.html < /dev/null

La correzione per goaccess è di far leggere il log da stdin invece di leggere dal file, quindi la soluzione è di cambiare la voce crontab in

cat /var/log/nginx/access.log | goaccess -a > output.html

Sui miei server RHEL7, i lavori di cron di root venivano eseguiti, ma i lavori degli utenti no. Ho trovato che senza una home directory, i lavori non saranno eseguiti (ma vedrete buoni errori in / var / log / cron). Quando ho creato la home directory, il problema è stato risolto.

Se hai modificato il tuo file crontab usando un editor di windows (tramite samba o qualcosa del genere) e hai sostituito le nuove righe con \ n \ r o semplicemente \ r, cron non verrà eseguito.

Inoltre, se stai usando /etc/cron.d/* e uno di quei file ha un \ r in esso, cron si muoverà attraverso i file e si fermerà quando raggiungerà un file non valido. Non sono sicuro se questo è il problema?

Usa:

od -c /etc/cron.d/* | grep \r