¿Cómo establecer variables de entorno global en el arranque a través de un script y tenerlas disponibles para una aplicación que se ejecuta antes de iniciar sesión?

Tengo un servicio que se ejecuta en el arranque, y en ese servicio llama a un script bash en segundo plano que exporta algunas variables de entorno. El problema que tengo es que esas variables de entorno no se envían al padre del proceso en segundo plano, por lo que tan pronto como mi script termina de ejecutarse, desaparecen.

Además, después de ejecutar el script, el servicio llama a otro script que inicia una aplicación que tengo. Esta aplicación necesita acceso a esas variables de entorno.

El sistema RHEL en el que lo ejecuto nunca debe iniciar sesión en el usuario, solo se inicia e inicia la aplicación. Yo sé que las variables de entorno para un proceso padre / corteza no pueden realmente ser establecidos por un fondo niño cáscara proceso de embargo.

Necesito una forma de hacerlo a través de un script que mi servicio llama (no necesariamente en segundo plano), no agregándolos en mi servicio (que tampoco funcionó para mí) y no almacenándolos en un /etc/environmento .profileo algo por el estilo.

En mi servicio intenté agregar las variables de entorno (aunque no es lo que quiero hacer):

    export TEST=192.168.1.1

También probé esto en mi servicio:

    TEST=192.168.1.1
    export TEST=${TEST}

Traté de cambiar cómo mi servicio llama al script bash:

    /bin/asdf/script &

También intenté obtener el script para que se ejecute en el mismo shell (que obtuve de esto ):

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

También encontré esto que parecía interesante, pero realmente no funcionó en mi caso.

— sqenixs
fuente

Respuestas:

Puede intentar poner un script para recopilar las variables en /etc/profile.d/

Ejemplo:

/etc/profile.d/somescript.sh

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

/etc/profilerealiza una llamada que ejecutará cualquier script /etc/profile.d/, y esto se aplica a todos los usuarios del sistema, incluido el root.

— madflojo
fuente

Puede que tengas algo aquí. Sin embargo, no quiero hacer exactamente eso, ya que el script no se puede ubicar en el directorio / etc por razones de IA. Pero creo que puedo crear un enlace simbólico allí que apunte a mi script. Pero para complicar las cosas, algunas de las variables de entorno establecidas por el script provienen de las variables de entorno establecidas por el servicio. Por lo tanto, esto podría no funcionar, ya que las variables ya deben establecerse antes de que el script de servicio llegue al final, pero no demasiado pronto o el servicio aún no habrá creado las variables de entorno necesarias.

— sqenixs

Supongo que puedo deshacerme de la dependencia de las variables establecidas en el servicio. En este caso, creo que funcionará, siempre que el script se ejecute antes de que se inicie el servicio. ¿Sabes cuándo se inicia el shell de inicio de sesión? ¿O puedo controlar cuándo se inicia el shell de inicio de sesión? No tengo un servicio para ello en el directorio rcX.d para mi nivel de ejecución.

— sqenixs

No hay forma de que un proceso influya en el entorno de otro proceso existente. Los procesos solo influyen en el entorno de sus procesos hijos.

Por lo tanto, debe establecer estas variables de entorno en un antecesor de la aplicación que las necesita. En lugar de que su servicio invoque por separado la secuencia de comandos bash que establece el entorno y la aplicación, haga que su servicio invoque una secuencia de comandos bash que establezca las variables de entorno y luego inicie la aplicación.

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

— Gilles 'SO- deja de ser malvado'
fuente

Sin embargo, por lo que he leído en línea, hay hacks (algo que tiene que ver con eval en un script de origen o con gdb) para que funcione. No estoy demasiado interesado en que esté en segundo plano, si puedo ejecutar los comandos en el "shell" actual (¿estás en un shell durante el arranque cuando se está ejecutando tu servicio?), Entonces eso también estaría bien.

— sqenixs

Desafortunadamente, no puedo iniciar la aplicación desde el servicio, ya que hay muchos procesos diferentes que se inician y cosas que se configuran desde el script de inicio de la aplicación, y deben mantenerse separados del servicio para IA.

— sqenixs

@sqenixs Un shell es un proceso como cualquier otro. No existe tal cosa como "estar en una concha". Cuando habla de "evaluar en un script de origen", ese es un protocolo en el que un programa (que puede no ser un script de shell) imprime definiciones en la sintaxis de shell, y un script de shell las interpreta. Establecer variables de entorno con gdb podría funcionar, o podría no tener efecto, o podría bloquear su aplicación; como se puede imaginar, no se recomienda usar un depurador en producción (y, nuevamente, por una buena razón).

— Gilles 'SO- deja de ser malvado'

Probablemente haya una solución a su problema, pero debe ser más preciso con sus requisitos. En su pregunta, escribe "después de ejecutar el script, el servicio llama a otro script que inicia una aplicación". Entonces parece que tiene una solución: establezca las variables de entorno dentro de ese otro script. Pero luego, en un comentario, escribe que "no puede iniciar la aplicación desde el servicio". Entonces, ¿cuál es?

— Gilles 'SO- deja de ser malo'

quizás, cree o configure el entorno de / sbin / init en el momento del arranque. Como todos los procesos son secundarios de init, el proceso secundario puede adquirir el entorno. Solo un pensamiento / suposición.

— Nikhil Mulley