eseguendo uno script sh dal cron

12

Ho uno script test.sh

#!/bin/sh
php /home/v/file.php
sh /root/x/some.sh

quando eseguo il file come root dalla riga di comando funziona.

sh /home/v/test.sh

quando l'ho impostato su crontab -e (è il cron cron), non funziona

 * * * * * sh /home/v/test.sh

Cosa faccio di sbagliato? Grazie

shell cron

— Elzo Valugi
fonte

"non funziona" non funziona. Vedere? Non sai cosa intendo, e come noi non sappiamo cosa intendi. Voglio dire (sì) cosa non funziona? Potrebbe trattarsi di qualsiasi cosa. Potrebbe essere che la supposizione sia corretta, ma è solo una supposizione (e piuttosto buona penso, ma comunque).

— Jürgen A. Erhard,

Sì, se puoi essere più specifico con quali risultati stai vedendo, saremo in grado di determinare meglio quale sia il problema. Cioè, cosa intendi con "non funzionante" (:

— gabe.

Non vedo alcun registro nel syslog, e gli script stanno facendo degli inserimenti in un db che non stanno accadendo, e loro accaderebbero se eseguissi lo script a mano.

— Elzo Valugi,

15

Secondo l'uomo:

Il demone cron avvia una subshell dalla directory HOME. Se si pianifica l'esecuzione di un comando quando non si è effettuato l'accesso e si desidera eseguire i comandi nel file .profile, il comando deve leggere esplicitamente il file .profile.

Il demone cron fornisce un ambiente predefinito per ogni shell, definendo HOME, LOGNAME, SHELL (= / usr / bin / sh)
e PATH (= / usr / bin).

Quindi il demone cron non sa dove si trova php e dovresti specificare il percorso php completo a mano, ad esempio (non conosco il tuo vero percorso PHP):

#!/bin/sh
/usr/local/bin/php /home/v/file.php
sh /root/x/some.sh

Un altro modo è quello di procurarsi il profilo / etc / (o il tuo .profile / .bashrc), per esempio

* * * * * . /home/v/.bashrc ; sh /home/v/test.sh

Questo è utile se il tuo .bashrc imposta le variabili d'ambiente che ti servono (es. PERCORSO)

MODIFICARE

Una lettura interessante è " Newbie: Intro to cron ", non sottovalutare l'articolo dal titolo (È una lettura per tutti), infatti è ben scritto completo e rispondi perfettamente alla tua domanda:

...
PATH contiene le directory che saranno nel percorso di ricerca di cron, ad esempio se hai un programma "pippo" nella directory / usr / cog / bin, potrebbe valere la pena aggiungere / usr / cog / bin al percorso, poiché ti impedirà di utilizzare il percorso completo per "pippare" ogni volta che vuoi chiamarlo.
...

— tmow
fonte

Bad $ PATH è la causa più comune di script che funzionano a mano, ma non da cron.

— Patrick,

@Patrick Naturalmente è un problema se cron non sa dove si trova php, altrimenti il crontab Elzo funzionerebbe senza problemi, DEVE essere un problema PATH.

— dal

Grazie mille per la tua risposta. Ha funzionato molto facilmente con me !!! .. Grazie mille @mow.

— Vignesh Prajapati,

5

Esistono quattro cause comuni per i comandi che funzionano quando digitato in un terminale ma non da cron, in ordine di comunanza:

Cron fornisce un ambiente limitato, ad esempio un minimo $PATHe altre variabili previste mancanti.
Cron richiama / bin / sh per impostazione predefinita, mentre potresti usare interattivamente un'altra shell.
Cron tratta il carattere% appositamente (viene trasformato in una nuova riga nel comando).
Cron non fornisce un ambiente terminale o grafico.

Se il tuo lavoro produce output, inclusi messaggi di errore, cron ti invia un'email con l'intero output. Assicurati di leggere la posta che ricevi localmente o di inoltrarla a un indirizzo che leggi. Per inoltrare la posta da un account locale a un altro indirizzo, inserisci l'altro indirizzo ~/.forward. Se il lavoro di cron è in esecuzione come utente del sistema ( root, webmaster, ...), assicurarsi che la posta di utente viene reindirizzato a voi (e qualsiasi altra admin); con la maggior parte delle configurazioni di posta, inserisci linee come root: elzoin /etc/aliases.

— Gilles 'SO- smetti di essere malvagio'
fonte

2

Il demone cron di solito esegue il comando in una shell in cui la variabile d'ambiente PATH è limitata ad alcune impostazioni predefinite del sistema, ad esempio / usr / bin: / bin.

Probabilmente, il tuo phpcomando non è disponibile in / usr / bin o / bin e quindi lo script fallisce quando viene eseguito tramite cron e viene eseguito correttamente quando non lo è.

Cron di solito segnala errori o messaggi di lavoro via e-mail all'utente root (ovvero quando un comando restituisce uno stato di uscita! = 0 o produce output su stdout / stderr) al termine del lavoro.

A seconda del sistema in uso, è necessario impostare la consegna della posta locale per ricevere questi messaggi.

— maxschlepzig
fonte