Come impostare le variabili di ambiente globali all'avvio tramite uno script e averle disponibili per un'applicazione che viene eseguita prima dell'accesso?

Ho un servizio che gira all'avvio e in quel servizio chiama in background uno script bash che esporta alcune variabili d'ambiente. Il problema che sto riscontrando è che quelle variabili di ambiente non vengono inviate al genitore del processo in background, quindi non appena l'esecuzione del mio script viene eseguita, scompaiono.

Inoltre, dopo l'esecuzione dello script, il servizio chiama un altro script che avvia un'applicazione che ho. Questa applicazione richiede l'accesso a tali variabili di ambiente.

Il sistema RHEL su cui lo eseguo non deve mai essere registrato dall'utente, si avvia e avvia l'applicazione. So che le variabili di ambiente per un processo genitore / shell non possono davvero essere impostate da un background bambino shell processo però.

Ho bisogno di un modo per farlo attraverso uno script che viene chiamato dal mio servizio (non necessariamente in background però), non aggiungendoli al mio servizio (che non ha funzionato neanche per me) e non memorizzandoli in un /etc/environmento .profileo qualcosa del genere.

Nel mio servizio ho provato ad aggiungere le variabili d'ambiente (non quello che voglio fare però):

    export TEST=192.168.1.1

Ho anche provato questo nel mio servizio:

    TEST=192.168.1.1
    export TEST=${TEST}

Ho provato a cambiare il modo in cui il mio servizio chiama lo script bash:

    /bin/asdf/script &

Ho anche provato a reperire lo script in modo che venga eseguito nella stessa shell (che ho ottenuto da questo ):

    . ./bin/asdf/script
    #I'm very confused why this didn't work

Ho anche trovato questo che sembrava interessante ma nel mio caso non ha funzionato.

— sqenixs
fonte

Risposte:

Puoi provare a mettere uno script in cui raccogliere le variabili /etc/profile.d/

Esempio:

/etc/profile.d/somescript.sh

#!/bin/bash
TEST=$(cat /var/somefile)
export $TEST

/etc/profileesegue una chiamata che eseguirà qualsiasi script /etc/profile.d/e questo vale per tutti gli utenti del sistema, incluso root.

— madflojo
fonte

Potresti essere su qualcosa qui. Non voglio fare esattamente questo però dal momento che lo script non può trovarsi nella directory / etc per motivi di IA. Ma penso di poter creare un link simbolico che punta alla mia sceneggiatura. Ma per complicare le cose, alcune delle variabili di ambiente impostate dallo script provengono da variabili di ambiente impostate dal servizio. Quindi potrebbe non funzionare, poiché le variabili devono essere già impostate prima che lo script del servizio giunga alla fine, ma non troppo presto o le variabili di ambiente necessarie non saranno ancora state create dal servizio.

— sqenixs,

Immagino di poter eliminare la dipendenza dalle variabili impostate nel servizio. In questo caso, penso che funzionerà, purché lo script venga eseguito prima dell'avvio del servizio. Sai quando viene avviata la shell di accesso? O posso controllare quando si avvia la shell di login? Non ho un servizio per esso nella directory rcX.d per il mio livello di esecuzione.

— sqenixs,

Non c'è modo per un processo di influenzare l'ambiente di un altro processo esistente. I processi influenzano solo l'ambiente dei loro processi figlio.

Quindi è necessario impostare queste variabili di ambiente in un antenato dell'applicazione che ne ha bisogno. Invece di fare in modo che il tuo servizio invochi separatamente lo script bash di impostazione dell'ambiente e l'applicazione, fai in modo che il tuo servizio invochi uno script bash che imposta le variabili di ambiente, quindi avvia l'applicazione.

#!/bin/bash
. /path/to/environment/variable/setter.bash
exec /path/to/application

— Gilles 'SO- smetti di essere malvagio'
fonte

Da quello che ho letto online, ci sono degli hack (qualcosa che ha a che fare con eval su uno script sorgente o usando gdb) per farlo funzionare. Non sono eccessivamente interessato al fatto che sia in background, se posso eseguire i comandi nella "shell" corrente (sei in una shell durante l'avvio quando il tuo servizio è in esecuzione?), Anche questo andrebbe bene.

— sqenixs,

Sfortunatamente, non riesco ad avviare l'applicazione dal servizio, poiché ci sono molti processi diversi che vengono avviati e cose che sono configurate dallo script di avvio dell'applicazione e devono essere tenuti separati dal servizio per IA.

— sqenixs,

@sqenixs Una shell è un processo come un altro. Non esiste qualcosa come "essere in un guscio". Quando parli di "eval su uno script di origine", si tratta di un protocollo in cui un programma (che potrebbe non essere uno script di shell) stampa le definizioni nella sintassi della shell e uno script di shell le interpreta. L'impostazione delle variabili di ambiente con gdb potrebbe funzionare o potrebbe non avere alcun effetto o potrebbe arrestare in modo anomalo l'applicazione; come puoi immaginare, l'uso di un debugger in produzione non è raccomandato (e, ancora, per una buona ragione).

— Gilles 'SO- smetti di essere malvagio' il

Probabilmente c'è una soluzione al tuo problema, ma devi essere più preciso con le tue esigenze. Nella tua domanda, scrivi "dopo l'esecuzione dello script il servizio quindi chiama un altro script che avvia un'applicazione". Quindi sembra che tu abbia una soluzione: imposta le variabili di ambiente all'interno di quell'altro script. Ma poi in un commento scrivi che "non puoi avviare l'applicazione dal servizio". Allora, che cos'è?

— Gilles 'SO- smetti di essere malvagio' il

forse, crea o configura l'ambiente di / sbin / init al momento dell'avvio. Poiché ogni processo è comunque figlio di init, il processo figlio può acquisire l'ambiente. Solo un pensiero / ipotesi.

— Nikhil Mulley,