Dove posso impostare le variabili d’ambiente che crontab userà?

Ho un crontab in esecuzione ogni ora. L’utente che lo esegue ha variabilità di ambiente nel file .bash_profile che funziona quando l’utente esegue il lavoro dal terminale, tuttavia, ovviamente questi non vengono rilevati da crontab quando viene eseguito.

Ho provato a impostarli in .profile e .bashrc ma non sembrano ancora essere rilevati. Qualcuno sa dove posso mettere le vars di ambiente che crontab può raccogliere?

Avere ‘cron’ eseguire uno script di shell che imposta l’ambiente prima di eseguire il comando.

Sempre.

 # @(#)$Id: crontab,v 4.2 2007/09/17 02:41:00 jleffler Exp $ # Crontab file for Home Directory for Jonathan Leffler (JL) #----------------------------------------------------------------------------- #Min Hour Day Month Weekday Command #----------------------------------------------------------------------------- 0 * * * * /usr/bin/ksh /work1/jleffler/bin/Cron/hourly 1 1 * * * /usr/bin/ksh /work1/jleffler/bin/Cron/daily 23 1 * * 1-5 /usr/bin/ksh /work1/jleffler/bin/Cron/weekday 2 3 * * 0 /usr/bin/ksh /work1/jleffler/bin/Cron/weekly 21 3 1 * * /usr/bin/ksh /work1/jleffler/bin/Cron/monthly 

Gli script in ~ / bin / Cron sono tutti collegamenti a un singolo script, ‘runcron’, che assomiglia a:

 : "$Id: runcron.sh,v 2.1 2001/02/27 00:53:22 jleffler Exp $" # # Commands to be performsd by Cron (no debugging options) # Set environment -- not done by cron (usually switches HOME) . $HOME/.cronfile base=`basename $0` cmd=${REAL_HOME:-/real/home}/bin/$base if [ ! -x $cmd ] then cmd=${HOME}/bin/$base fi exec $cmd ${@:+"[email protected]"} 

(Scritto usando uno standard di codifica più vecchio – al giorno d’oggi, userei un “#!” Shebang all’inizio).

‘~ / .Cronfile’ è una variante del mio profilo per l’uso da parte di cron – rigorosamente non intertriggers e senza eco per il gusto di essere rumoroso. Potresti organizzare l’esecuzione del .profile e così via. (La roba di REAL_HOME è un artefatto del mio ambiente – puoi fingere che sia uguale a $ HOME.)

Quindi, questo codice legge l’ambiente appropriato e quindi esegue la versione non Cron del comando dalla mia directory home. Quindi, ad esempio, il mio comando “giorno della settimana” ha il seguente aspetto:

 : "@(#)$Id: weekday.sh,v 1.10 2007/09/17 02:42:03 jleffler Exp $" # # Commands to be done each weekday # Update ICSCOPE n.updics 

Il comando ‘giornaliero’ è più semplice:

 : "@(#)$Id: daily.sh,v 1.5 1997/06/02 22:04:21 johnl Exp $" # # Commands to be done daily # Nothing -- most things are done on weekdays only exit 0 

È ansible definire variabili d’ambiente nel crontab stesso quando si esegue crontab -e dalla riga di comando.

 LANG=nb_NO.UTF-8 LC_ALL=nb_NO.UTF-8 # mh dom mon dow command * * * * * sleep 5s && echo "yo" 

Questa funzione è disponibile solo per alcune implementazioni di cron. Ubuntu e Debian attualmente usano vixie-cron che consente di dichiararli nel file crontab (anche GNU mcron ).

Archlinux e RedHat utilizzano cronie che non consente la dichiarazione delle variabili di ambiente e genera errori di syntax nel cron.log. È ansible fare una soluzione alternativa per ogni entrata:

 # mh dom mon dow command * * * * * export LC_ALL=nb_NO.UTF-8; sleep 5s && echo "yo" 

Ho un’altra soluzione per questo problema:

 0 5 * * * . $HOME/.profile; /path/to/command/to/run 

In questo caso sceglierà tutte le variabili d’ambiente definite nel file $ HOME / .profile.

Ovviamente $ HOME non è impostato, devi sostituirlo con il percorso completo di $ HOME.

Anche l’impostazione di vars in /etc/environment ha funzionato per me in Ubuntu. A partire dal 12.04, le variabili in / etc / environment sono caricate per cron.

L’espansione sull’esempio @carestad, che trovo più semplice, consiste nell’eseguire lo script con cron e avere l’ambiente nello script.

Nel file crontab -e:

 SHELL=/bin/bash */1 * * * * $HOME/cron_job.sh 

Nel file cron_job.sh:

 #!/bin/bash source $HOME/.bash_profile some_other_cmd 

Qualsiasi comando dopo l’origine di .bash_profile avrà il tuo ambiente come se avessi effettuato l’accesso.

Per me ho dovuto impostare la variabile di ambiente per un’applicazione php. L’ho resloved aggiungendo il seguente codice al mio crontab.

 $ sudo crontab -e 

crontab:

 ENVIRONMENT_VAR=production * * * * * /home/deploy/my_app/cron/cron.doSomethingWonderful.php 

e dentro doSomethingWonderful.php potrei ottenere il valore dell’ambiente con:

  "production" 

Spero che aiuti!

Qualsiasi cosa tu abbia impostato in crontab sarà disponibile nei cronjobs, sia direttamente che usando le variabili negli script.

Usali nella definizione del cronjob

Puoi configurare crontab modo che imposti le variabili che poi possono usare il cronjob:

 $ crontab -l myvar="hi man" * * * * * echo "$myvar. date is $(date)" >> /tmp/hello 

Ora il file /tmp/hello mostra cose come:

 $ cat /tmp/hello hi man. date is Thu May 12 12:10:01 CEST 2016 hi man. date is Thu May 12 12:11:01 CEST 2016 

Usali nello script eseguito da cronjob

È ansible configurare crontab modo che imposti le variabili che possono essere utilizzate dagli script:

 $ crontab -l myvar="hi man" * * * * * /bin/bash /tmp/myscript.sh 

E dire che lo script /tmp/myscript.sh è come questo:

 echo "Now is $(date). myvar=$myvar" >> /tmp/myoutput.res 

Genera un file /tmp/myoutput.res mostra:

 $ cat /tmp/myoutput.res Now is Thu May 12 12:07:01 CEST 2016. myvar=hi man Now is Thu May 12 12:08:01 CEST 2016. myvar=hi man ... 

L’espansione su @Robert Brisita si è appena espansa, anche se non si desidera impostare tutte le variabili del profilo nello script, è ansible selezionare le variabili da esportare nella parte superiore dello script

Nel file crontab -e:

 SHELL=/bin/bash */1 * * * * /Path/to/script/script.sh 

In script.sh

 #!/bin/bash export JAVA_HOME=/path/to/jdk some-other-command 

Invece di

 0 * * * * sh /my/script.sh 

Usa bash -l -c

 0 * * * * bash -l -c 'sh /my/script.sh' 

Un altro modo – ispirato da questa risposta – per “iniettare” le variabili è il seguente (esempio fcron):

 %daily 00 12 \ set -a; \ . /path/to/file/containing/vars; \ set +a; \ /path/to/script/using/vars 

Dal help set :

-a Contrassegna le variabili che vengono modificate o create per l’esportazione.

L’utilizzo di + anziché di – provoca la distriggerszione di questi flag.

Quindi tutto tra set - e set + viene esportato in env ed è quindi disponibile per altri script, ecc. Senza usare set le variabili vengono acquisite ma vivono solo in set .

A parte questo, è anche utile passare le variabili quando un programma richiede l’esecuzione di un account non-root, ma è necessario disporre di alcune variabili all’interno dell’ambiente di quell’altro utente. Di seguito è riportato un esempio di passaggio in vars nullmailer per formattare l’intestazione dell’e-mail:

 su -s /bin/bash -c "set -a; \ . /path/to/nullmailer-vars; \ set +a; \ /usr/sbin/logcheck" logcheck 

Se avvii gli script che stai eseguendo tramite cron con:

#!/bin/bash -l

Dovrebbero raccogliere le tue variabili di ambiente ~ / .bash_profile

Ho provato la maggior parte delle soluzioni fornite, ma all’inizio non ho funzionato. Si scopre, tuttavia, che non sono state le soluzioni a non funzionare. Apparentemente, il mio file ~/.bashrc inizia con il seguente blocco di codice:

 case $- in *i*) ;; *) return;; esac 

Questa è fondamentalmente case statement che controlla il set corrente di opzioni nella shell corrente per determinare che la shell sia in esecuzione in modo interattivo. Se la shell è in esecuzione in modo interattivo, passa al sourcing del file ~/.bashrc . Tuttavia, in una shell richiamata da cron , la variabile $- non contiene il valore i che indica l’interattività. Pertanto, il file ~/.bashrc non viene mai acquisito completamente. Di conseguenza, le variabili d’ambiente non sono mai state impostate. Se questo è il tuo problema, sentiti libero di commentare il blocco di codice come segue e riprova:

 # case $- in # *i*) ;; # *) return;; # esac 

Spero che questo si riveli utile