Perché la mia riga di comando non viene eseguita da cron?

Question

Ho uno script perl (parte della famiglia XMLTV di "grabber", in particolare tv_grab_oztivo).

posso correre con successo in questo modo:

/sw/bin/perl /path/to/tv_grab_oztivo --output /path/to/tv.xml 

Io uso i percorsi completi per tutto per eliminare i problemi con la directory di lavoro. Le autorizzazioni non dovrebbero essere un problema.

Quindi, se lo avvio dal terminale (Mac OSX) funziona perfettamente.

Ma quando l'ho impostato per essere eseguito tramite un cron job, non sembra che accada nulla. Nessuna uscita è stata creata ecc.

Non c'è niente di sbagliato con il crontab, per quanto posso vedere, perché se sostituisco un helloworld.pl per lo script vero e proprio, funziona perfettamente al momento giusto.

Quindi, cosa posso fare per eseguire il debug? Posso vedere guardando %ENV nei due casi in cui l'ambiente è molto diverso, ma quali altri approcci posso adottare per il debug? Come posso vedere l'output del job cron, che potrebbe essere una sorta di messaggio "die" perl o "non trovato" dalla shell o altro?

O dovrei provare a dare in qualche modo alla versione di cron del comando lo stesso ambiente di quando è in esecuzione come me?

Answer 1

È spesso perché non si ottiene l'intero ambiente quando si esegue in cron. Cosa migliore da fare è quello di catturare l'output utilizzando il comando:

(/sw/bin/perl /path/to/tv_grab_oztivo ...) >/tmp/qq 2>&1 

e poi dare un'occhiata a /tmp/qq.

Se non rivelarsi un ambiente mancante, quindi potrebbe essere necessario mettere:

. ~/.profile 

o qualcosa di simile, nella catena di esecuzione del vostro lavoro cron, come ad esempio:

(. ~/.profile ; /sw/bin/perl /path/to/tv_grab_oztivo ...) >/tmp/qq 2>&1 

Answer 2

cron di solito acquisisce l'output di stdout e stderr e invia via e-mail qualsiasi output al proprietario di crontab.

Hai ricontrollato la tua voce di crontab per assicurarti che sia valida e venga eseguita al momento giusto?

Assicurarsi che lo script non abbia bisogno di alcuna variabile di ambiente impostata. Altrimenti, avvolgilo in un altro script (bash), in cui puoi impostare le variabili di ambiente che l'altro script si aspetta.

Answer 3

Se guardi a% ENV nei due casi, suggerirei che, come primo passo nel tuo script perl, imposta% ENV su ciò che è in un cron job, e quindi prova ad eseguirlo dal riga di comando. Potrebbe essere necessario exec soli una volta per questo di prendere il pieno controllo:

BEGIN { 
    if (exists $ENV{something_in_your_env_not_in_cron}) { 
    %ENV = (...); 
    exec $^X, $0, @ARGV; 
    } 
} 

Ora provare a eseguire esso, e vedere se c'è qualcosa che puoi fare per eseguire il debug (tra cui l'esecuzione sotto perl -d se necessario).Molto probabilmente, scoprirai che si finisce per aggiungere nuovamente gli elementi in% ENV uno alla volta fino a quando inizia magicamente a funzionare (LD_LIBRARY_PATH è una buona soluzione per questo, ma ORACLE_HOME o DB2HOME per le app Oracle o DB2 potrebbero essere anche buone scelte). Quindi puoi impostare la variabile nel tuo script o nel crontab.

Answer 4

Avrei eseguito uno script di shell semplice per il percorso assoluto dal comando cron. All'interno di quello script, mi assicuravo di aver intrappolato stdout e stderr in un file noto (o conoscibile). Mi piacerebbe anche che fosse impostato abbastanza del tuo ambiente. Su Unix, non si ottiene quasi nessun ambiente impostato quando si esegue un comando tramite cron - Non sono sicuro di MacOS X. Il colpevole standard dei problemi è PATH. Ho uno .cronfile separato che imposta il mio ambiente di lavoro abbastanza da non avere problemi di solito - questo è un analogo di .profile.

Answer 5

In alcuni casi, se non riesci a capire cosa non va nella tua riga di comando, il modo più semplice per risolverlo è trasformare tutto in uno script di shell. Idealmente non si dovrebbe avere per fare questo, ma può essere il modo più veloce per risolvere il problema.

File: /files/cron1.sh

#!/bin/sh 
/sw/bin/perl /path/to/tv_grab_oztivo --output /path/to/tv.xml 

E poi nel cron:

/files/cron1.sh 

Questo permette di testare lo script indipendente da cron. Ricorda però che la tua shell di login funziona con variabili d'ambiente diverse da quelle di cron.