Come posso eseguire un comando cron con variabili ambientali esistenti?

Come posso eseguire un comando cron con variabili ambientali esistenti?

Se sono al prompt della shell, posso digitare echo $ORACLE_HOMEe ottenere un percorso. Questa è una delle mie variabili ambientali che viene impostata nel mio ~/.profile. Tuttavia, sembra che ~/.profilenon venga caricato dagli script cron e quindi i miei script non riescono perché la $ORACLE_HOMEvariabile non è impostata.

In questa domanda l'autore menziona la creazione di un ~/.cronfileprofilo che imposta le variabili per cron, quindi esegue una soluzione alternativa per caricare tutti i suoi comandi cron negli script che mantiene nella sua ~/Crondirectory. Un file come ~/.cronfilesembra una buona idea, ma il resto della risposta sembra un po 'ingombrante e speravo che qualcuno potesse dirmi un modo più semplice per ottenere lo stesso risultato.

Suppongo che all'inizio dei miei script potrei aggiungere qualcosa del genere, source ~/.profilema sembra che potrebbe essere ridondante.

Quindi, come posso fare in modo che i miei script cron caricino le variabili dal mio profilo della shell interattiva?

Nel crontab, prima di comandare, aggiungi . $HOME/.profile. Per esempio:

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

Cronnon sa nulla del tuo guscio; è avviato dal sistema, quindi ha un ambiente minimo. Se vuoi qualcosa, devi averlo portato dentro di te.

Un'altra opzione, che trovo più semplice, è 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.

Un'altra opzione, che trovo più semplice, è eseguire lo script con cron e dire a bash di accedere (quindi usando /etc/profile.d/...le definizioni di ambiente)

Nel crontab -efile:

*/1 * * * * bash -l -c './cron_job.sh'
*/1 * * * * bash -l -c 'php -f ./cron_job.php'

Qualsiasi comando dopo la fonte di .bash_profileavrà il tuo ambiente come se avessi effettuato l'accesso.

Cattiva idea. La pratica generale è impostare in modo specifico tutte le variabili ambientali richieste in uno script che deve essere eseguito da un cron job.

Questa sintassi ti aiuta sicuramente. Non capisco la sintassi, ma funziona. Oracle utilizza questa sintassi, quando distribuisce Oracle Configuration Manager per crontab, quindi credo che questa sia la soluzione giusta.

0 5 * * * SOME_ENV_VAR=some_value some_command some_parameters

Di recente mi sono imbattuto in un caso in cui dovevo eseguire il cronjob generale come root ma, allo stesso tempo, dovevo eseguire un sottocomando come utente diverso (che richiedeva l'approvvigionamento dell'ambiente di quell'utente). Sono andato con il seguente approccio:

# m  h  dom  mon  dow  user  command
*/5  *   *    *    *   root  (sudo -i -u <the user> command-to-be-run-as-user) && command-to-be-run-as-root

La parte cruciale è l'argomento a -icui viene passato sudoche eseguirà il comando dato in una shell di login separata (che a sua volta significa che i dotfile dell'utente verranno forniti).

PS: Si noti che la usercolonna è disponibile solo nei /etc/crontabe dei /etc/cron.d/*file.

La soluzione, che ha funzionato per me, è descritta qui .

Si crea uno script wrapper, che chiama . ~/.cronfilee quindi fa le cose che vuoi. Questo script è lanciato da cron.

In ~/.cronfilesi specifica l'ambiente per i lavori cron.

Sì, puoi usare "soluzioni alternative ben note" (alcune delle quali sono state elencate). Questo è un altro modo per dire che tutti sanno che è scadente, anche se alcune persone si riferiranno a questa come una "caratteristica di sicurezza" perché hanno speso almeno tanto inciampare su questo fallimento (sì) come hai fatto, e vorrebbero pensare al loro il tempo sprecato non era per nulla. È l'equivalente cron della tastiera QWERTY.

Ho il sospetto che il motivo originale potrebbe essere stato per le prestazioni, in modo che gli script eseguiti una volta al minuto non passino il tempo a leggere gli script rc. Anche originariamente cron non era affatto configurabile, quindi un default era davvero l'unica opzione.

Non vi è alcuna sicurezza aggiuntiva non avendo una semplice configurazione o metodo per fare in modo che cron acquisisca semplicemente l'ambiente della shell interattiva invece che gli utenti debbano eseguire una stupida ginnastica con shell. Su una macchina moderna non vi è generalmente alcun miglioramento percepibile delle prestazioni a meno che non si abbia una grande quantità di lavori in esecuzione ogni minuto.

La cultura Unix fallisce. A mio modesto parere. :-)

Inserisci

BASH_ENV=/home/user/.profile

al crontab. Vedi Come garantire la disponibilità di $ BASH_ENV

Invece di impostare il profilo, ciò che mi ha aiutato è stato impostare il PATH. Alcuni dei comandi non erano disponibili nei miei script cron poiché PATHsono diversi.

ENVIRONMENT=prod
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
*/30 * * * * /opt/myscript1.sh
*/30 * * * * /opt/myscript2.sh
*/30 * * * * /opt/myscript3.sh

L'impostazione PATHcon il percorso dei comandi mi ha aiutato. Ancora meglio se puoi usare un modello e detemplatize in seguito,

ENVIRONMENT={{ENVIRONMENT}}
PATH={{PATH}}
*/30 * * * * /opt/myscript1.sh
*/30 * * * * /opt/myscript2.sh
*/30 * * * * /opt/myscript3.sh

Passare le variabili a ciascun elemento sembra disordinato.

Metto . ~/.dbus/session-bus/*nella parte superiore del mio copione desiderato :)