J'ai construit une application et une unité systemd pour cela. L'unité systemd fonctionne bien, mais comme les environnements de développement et de production ont divergé, j'ai commencé à déplacer la configuration vers les variables d'environnement et je n'arrive pas à les faire fonctionner dans systemd.
J'ai essayé des variables d'environnement à l'échelle du système, et elles sont visibles par le système d'exploitation, mais pas par le programme, j'ai donc commencé à chercher à les construire en unités systemd.
J'ai d'abord essayé d'utiliser EnvironmentFile
J'ai créé un fichier d'environnement qui avait simplement
LCSQLH=localhost
LCSQLU=application
en elle comme /etc/lc.sh
et
[Unit]
Description=Service for this app
[Service]
EnvironmentFile=/etc/lc.sh
ExecStart=/usr/bin/env python /opt/app/__init__.py
a fait un systemctl --system daemon-reload
mais non, mon application a commis une erreur:
Jan 27 14:24:59 machine.Host env[630]: KeyError: 'LCSQLU'
J'ai vu que certains avaient:
EnvironmentFile=-/etc/lc.sh
J'ai essayé ça ... non ...
J'ai donc essayé de les mettre individuellement
[Service]
Environment="LCSQLH=localhost"
Environment="LCSQLU=application"
ExecStart=/usr/bin/env python /opt/app/__init__.py
Encore une fois, non ...
J'ai donc entendu parler de l'idée de /etc/systemd/service_name.service.d
j'ai donc mis un service.conf dedans avec les environnements (même format que ci-dessus) mais non ...
Mon application n'a pas accès à ces variables d'environnement.
Si je les exporte (soit manuellement dans mon shell ou en utilisant /etc/profile.d/) et que j'exécute mon application directement, cela fonctionne, c'est donc que ceux-ci ne sont pas définis plutôt qu'un problème d'application.
Il s'agit de Centos 7.3 et j'ai choisi des variables d'environnement plutôt qu'une configuration codée en dur car elle peut s'exécuter sur Linux ou Windows, donc je ne veux pas enterrer un fichier de configuration dans/etc /
J'ai rencontré le même problème sur RHEL 7.3 et j'ai trouvé this :
Vous pouvez ensuite vous référer aux variables définies dans le
/etc/sysconfig/httpd
fichier avec${FOOBAR}
et$FOOBAR
, dans les lignesExecStart
(et les lignes associées).
Cela me fait penser que le but de Environment
et EnvironmentFile
n'est pas du tout ce que vous et moi attendions (définir des variables d'environnement pour le processus démarré par l'unité systemd), mais ne s'applique que pour l'immédiat extension de la ligne ExecStart
.
Peut-être que je suis complètement hors de la base et c'est un bogue dans systemd (je l'espère). Mais j'ai arrêté de suivre le chemin que vous essayez et je l'ai fait d'une autre manière: dans mon cas, je devais définir LD_LIBRARY_PATH
, donc je l'ai fait en créant /etc/ld.so.conf.d/new_file.conf
puis en exécutant ldconfig
. J'ai également essayé d'utiliser des variables à l'échelle du système dans /etc/profile.d/new_file.sh
, mais apparemment juste LD_LIBRARY_PATH
était suffisant pour ce service (mariadb) et je ne sais donc pas si les variables que je définissais dans /etc/profile.d/new_file.sh
fonctionnait.
Environment
et EnvironmentFile
définissent les variables, utilisables par l'unité, mais comme la commande sh
, ne l'exportent pas vers les processus enfants. Pour cela, vous devez également le répertorier dans PassEnvironment
, comme vous le feriez avec la commande Shell export
. Voir la documentation systemd sur EnvironmentFile et PassEnvironment
Notez également que le contenu d'un EnvironmentFile n'est pas un script Shell, mais des paires clé-valeur qui ressemblent un peu trop à sh, donc le nommer avec un .sh
l'extension est trompeuse.