Si encuentras algún fallo con tu código o proyecto, recuerda probar siempre en un entorno de testing antes aplicar el código al trabajo final.
Solución:
Solución 1:
Los tiempos cambian y también las mejores prácticas.
los Actual la mejor manera de hacer esto es correr systemctl edit myservice, que creará un archivo de reemplazo para usted o le permitirá editar uno existente.
En instalaciones normales, esto creará un directorio. /etc/systemd/system/myservice.service.d, y dentro de ese directorio cree un archivo cuyo nombre termine en .conf (típicamente, override.conf), y en este archivo puede agregar o anular cualquier parte de la unidad enviada por la distribución.
Por ejemplo, en un archivo /etc/systemd/system/myservice.service.d/myenv.conf:
[Service]
Environment="SECRET=pGNqduRFkB4K9C2vijOmUDa2kPtUhArN"
Environment="ANOTHER_SECRET=JP8YLOc2bsNlrGuD6LVTq7L36obpjzxd"
También tenga en cuenta que si el directorio existe y está vacío, ¡su servicio se desactivará! Si no tiene la intención de poner algo en el directorio, asegúrese de que no exista.
Como referencia, la forma antigua era:
La forma recomendada de hacer esto es crear un archivo /etc/sysconfig/myservice que contiene sus variables, y luego cárguelos con EnvironmentFile.
Para obtener detalles completos, consulte la documentación de Fedora sobre cómo escribir un script systemd.
Solucion 2:
La respuesta depende de si se supone que la variable es constante (es decir, que el usuario que obtiene la unidad no debe modificarla) o variable (que se supone que debe establecer el usuario).
Dado que es su unidad local, el límite es bastante borroso y de cualquier manera funcionaría. Sin embargo, si comenzaras a distribuirlo y terminaría en /usr/lib/systemd/system, esto se volvería importante.
Valor constante
Si el valor no necesita cambiar por instancia, la forma preferida sería colocarlo como Environment=, directamente en el archivo de la unidad:
[Unit]
Description=My Daemon
[Service]
Environment="FOO=bar baz"
ExecStart=/bin/myforegroundcmd
[Install]
WantedBy=multi-user.target
La ventaja de eso es que la variable se mantiene en un solo archivo con la unidad. Por lo tanto, el archivo de la unidad es más fácil de mover entre sistemas.
Valor variable
Sin embargo, la solución anterior no funciona bien cuando se supone que sysadmin debe cambiar el valor de la variable de entorno localmente. Más específicamente, el nuevo valor debería establecerse cada vez que se actualice el archivo de la unidad.
Para este caso, se debe utilizar un archivo adicional. Cómo: generalmente depende de la política de distribución.
Una solución particularmente interesante es utilizar /etc/systemd/system/myservice.service.d directorio. A diferencia de otras soluciones, este directorio es compatible con systemd y, por lo tanto, no incluye rutas específicas de distribución.
En este caso, coloca un archivo como /etc/systemd/system/myservice.service.d/local.conf que agrega las partes que faltan del archivo unitario:
[Service]
Environment="FOO=bar baz"
Posteriormente, systemd fusiona los dos archivos al iniciar el servicio (recuerde systemctl daemon-reload después de cambiar cualquiera de ellos). Y dado que systemd usa esta ruta directamente, no usa EnvironmentFile= para esto.
Si se supone que el valor debe cambiarse solo en algunos de los sistemas afectados, puede combinar ambas soluciones, proporcionando un valor predeterminado directamente en la unidad y una anulación local en el otro archivo.
Solución 3:
http://0pointer.de/public/systemd-man/systemd.exec.html#Environment= – tiene dos opciones (una ya señalada por Michael):
Environment=
y
EnvironmentFile=
Solución 4:
Las respuestas de Michael y Michał son útiles y responden a la pregunta original de cómo establecer una variable de entorno para un servicio systemd. Sin embargo, un uso común de las variables de entorno es configurar datos confidenciales como contraseñas en un lugar que no se comprometa accidentalmente con el control de la fuente con el código de su aplicación.
Si es por eso que desea pasar una variable de entorno a su servicio, no usar Environment= en el archivo de configuración de la unidad. Usar EnvironmentFile= y apúntelo a otro archivo de configuración que solo sea legible por la cuenta de servicio (y los usuarios con acceso root).
Los detalles del archivo de configuración de la unidad son visibles para cualquier usuario con este comando:
systemctl show my_service
Pongo un archivo de configuración en /etc/my_service/my_service.conf y pongo mis secretos ahí:
MY_SECRET=correcthorsebatterystaple
Luego, en mi archivo de unidad de servicio, usé EnvironmentFile=:
[Unit]
Description=my_service
[Service]
ExecStart=/usr/bin/python /path/to/my_service.py
EnvironmentFile=/etc/my_service/my_service.conf
User=myservice
[Install]
WantedBy=multi-user.target
Lo comprobé ps auxe no puede ver esas variables de entorno y otros usuarios no tienen acceso a /proc/*/environ. Compruebe en su propio sistema, por supuesto.
Solución 5:
Michael dio una solución limpia, pero quería obtener la variable env actualizada desde el script. Desafortunadamente, la ejecución de comandos bash no es posible en el archivo de unidad systemd. Afortunadamente, puede activar bash dentro de ExecStart:
http://www.dsm.fordham.edu/cgi-bin/man-cgi.pl?topic=systemd.service§=5
Tenga en cuenta que esta configuración no admite directamente las líneas de comando de shell. Si se van a utilizar líneas de comandos de shell, deben pasarse explícitamente a una implementación de shell de algún tipo.
El ejemplo en nuestro caso es entonces:
[Service]
ExecStart=/bin/bash -c "ENV=`script`; /bin/myforegroundcmd"
Nos puedes favorecer nuestra labor fijando un comentario o valorándolo te lo agradecemos.