web-dev-qa-db-fra.com

Variables à l'échelle du système pour les scripts d'initialisation et le système?

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?

3
Bevor

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

1
Bevor

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.

3
Robert Riedl