J'ai créé mes propres scripts d'initialisation qui utilisent des variables:
#! /bin/sh
case "$1" in
start)
echo "Starting Public API"
Sudo -u techops sh ${JBOSS_HOME_PUBLIC_API}/bin/standalone.sh > ${PUBLICAPI_LOGGING_PATH} &
;;
stop)
echo "Stopping Public API"
Sudo -u techops sh ${JBOSS_HOME_PUBLIC_API}/bin/jboss-cli.sh --connect --controller=localhost:$((9990 + $PUBLICAPI_PORT_OFFSET)) command=:shutdown > ${PUBLICAPI_LOGGING_PATH} &
;;
*)
echo "Usage: /etc/init.d/publicapi {start|stop}"
exit 1
;;
esac
exit 0
Les variables sont définies dans /etc/environment
et ressemble ainsi:
PUBLICAPI_PORT_OFFSET=0
PUBLICAPI_LOGGING_PATH=/var/log/publicapi/publicapi.log
JBOSS_HOME_PUBLIC_API=/opt/publicapi
... et fonctionne après la connexion, lorsque je démarre et arrête le script d'initialisation manuellement, mais ils ne fonctionnaient pas pour les scripts d'initialisation de démarrage (qui sont des liens symboliques vers /etc/init.d/publicapi
dans /etc/rc2.d/
, /etc/rc5.d/
, /etc/rc6.d/
). Le démarrage se bloque alors, car les variables sont inconnues.
J'ai pu résoudre ce problème en exécutant systemctl edit publicapi
qui a créé un fichier /etc/systemd/system/publicapi.service.d/local.conf
qui ressemble à ceci après l'avoir édité:
[Unit]
Description=Public API startup script
Documentation=no documentation
[Service]
Environment="JBOSS_HOME_PUBLIC_API=/opt/publicapi"
Environment="PUBLICAPI_PORT_OFFSET=0"
Environment="PUBLICAPI_LOGGING_PATH=/var/log/publicapi/publicapi.log"
lorsque je redémarre, le démarrage du script init fonctionne. Mais maintenant, j'ai une situation étrange: j'ai toujours besoin de définir la variable à la fois dans /etc/systemd/system/publicapi.service.d/local.conf
et en /etc/environment
. Si j'omets ceux de /etc/environment
, les scripts de démarrage init sont exécutés mais se bloquent, car les variables semblent ne pas être définies (au moins après la connexion). si je commente les variables dans /etc/systemd/system/publicapi.service.d/local.conf
et les mettre dans /etc/environment
uniquement, les variables sont définies après la connexion, mais les scripts de démarrage init ne sont pas exécutés. Qu'est-ce qui se passe ici? Quelle est la portée de /etc/systemd/system/publicapi.service.d/local.conf
(puisque les valeurs ont évidemment disparu après la connexion ou n'ont peut-être pas été définies)? Comment puis-je définir les variables une seule fois globalement?
Je peux répondre à la question moi-même maintenant. Après avoir perdu une demi-journée avec cette merde de bricoleur, j'ai une solution qui fonctionne. Il n'y a plus de scripts d'initialisation dans /etc/init.d/ ou /etc/rcX.d) ou ailleurs:
*) /etc/environment
JBOSS_HOME_CONSENT_SERVER=/opt/consent-server
CONSENT_SERVER_LOGGING_PATH=/var/log/consentserver/consent-server.log
CONSENT_SERVER_PORT_OFFSET=3000
*) dans /home/techops
créer un script consent-server
avec ce contenu:
#!/bin/sh
case "$1" in
start)
echo "Starting Consent Server"
Sudo -u techops sh ${JBOSS_HOME_CONSENT_SERVER}/bin/standalone.sh > ${CONSENT_SERVER_LOGGING_PATH} &
;;
stop)
echo "Stopping Consent Server"
Sudo -u techops sh ${JBOSS_HOME_CONSENT_SERVER}/bin/jboss-cli.sh --connect --controller=localhost:$((9990 + $CONSENT_SERVER_PORT_OFFSET)) command=:shutdown > ${CONSENT_SERVER_LOGGING_PATH} &
;;
*)
echo "Usage: systemctl {start|stop} consent-server or pass {start|stop} as parameter"
exit 1
;;
esac
exit 0
*) Créez un fichier /etc/systemd/system/consent-server.service
avec ce contenu:
[Unit]
Description=consent server startup script
[Service]
Type=oneshot
RemainAfterExit=yes
#if type=oneshot and RemainAfterExit=yes is not set, then the script stops immediately!
EnvironmentFile=-/etc/environment
WorkingDirectory=/home/techops
ExecStart=/home/techops/consent-server start
ExecStop=/home/techops/consent-server stop
[Install]
WantedBy=multi-user.target
*) Activer le service (créera un lien symbolique):
systemctl enable consent-server.service
Après le redémarrage, le service démarre automatiquement et toutes les variables sont reconnues. Vous pouvez également démarrer et arrêter le service avec systemctl start consent-server systemctl stop consent-server
Ce qui se passe ici, c'est que vous écrivez un script d'initialisation du système V sur un système qui exécute systemd.
Votre systemd est quelque peu rétrocompatible et exécutera ces scripts d'initialisation à l'ancienne dans une sorte d'émulation, mais traitez-les comme systemd.
Je pense que vous aurez un meilleur moment d'abandonner votre ancien script init et d'écrire un nouveau service systemd. De cette façon, vous n'avez pas besoin de /etc/environment
.
Voici quelques lectures supplémentaires sur la façon d'écrire les services systemd.