«Service» - commande et variables d'environnement

8

J'essaie de démarrer un service qui nécessite un env. variable à définir sur un certain chemin. J'ai défini cette variable dans "/etc/profile.d/". Cependant, lorsque je démarre ce service à l'aide de la servicecommande, cela ne fonctionne pas.

service homme:

service runs a System V init script in as predictable environment as possible,
removing most environment variables and with current working directory set to /.

Il semble donc que la servicesuppression de mes variables. Comment dois-je configurer les variables pour les empêcher d'être supprimées. Ou est-ce quelque chose que je ne devrais pas faire.

Je pourrais démarrer le service manuellement en utilisant les scripts d'initialisation, ou même coder en dur le chemin dans le script, mais j'aimerais savoir comment l'utiliser avec la servicecommande.

linux centos redhat service environment-variables Esa Varemo
la source

Réponses:

4

À partir de Fedora 16, servicen'accepte LANGque TERMles variables d'environnement, tout le reste est rejeté. Donc, même si votre {CentOS, RHEL} actuel accepte les variables d'une manière ou d'une autre, soyez prêt pour l'avenir où cela ne fonctionnera plus.

Donc, coder en dur le script init et / ou configurer les variables dans le fichier de paramètres du démon lui-même serait votre choix.

Janne Pikkarainen
la source
L'inconvénient est que chaque fois que je mets à jour l'application, je dois changer le fichier, mais je suppose que je dois juste ... (... pas mettre à jour souvent)
Esa Varemo
Eh bien, la «mise à jour fréquente» est une norme de nos jours. Vivre avec.
Janne Pikkarainen
6

Il est recommandé de placer les paramètres de configuration dans une configuration dans /etc/sysconfig/<servicename>laquelle est ensuite lu par le script init.

Cordialement

Bram

Bram
la source
Comme autre astuce dans le /etc/sysconfig/<servicename>fichier, vous pouvez utiliser bash sourcepour charger des fichiers à partir /etc/profile.dd'imiter l'environnement de connexion shell.
Adam Gent
2

De man 5 init:

   Environnement de travail
       Chaque travail est exécuté avec l'environnement à partir des événements ou des commandes qui l'ont démarré. En outre, vous pouvez définir des valeurs par défaut dans le
       travail qui peut être remplacé ultérieurement et spécifiez les variables d'environnement à exporter dans les événements générés pour le travail.

       La variable d'environnement spéciale UPSTART_EVENTS contient la liste des événements qui ont démarré le travail, elle ne sera pas présente si le
       le travail a été démarré manuellement.

       De plus, les scripts pré-arrêt et post-arrêt sont exécutés avec l'environnement des événements ou des commandes qui ont arrêté le travail.
       La variable d'environnement UPSTART_STOP_EVENTS contient la liste des événements qui ont arrêté le travail, elle ne sera pas présente si le travail
       a été arrêté manuellement.

       Tous les travaux contiennent également les variables d'environnement UPSTART_JOB et UPSTART_INSTANCE, contenant le nom du travail et de l'instance.
       Celles-ci sont principalement utilisées par l'utilitaire initctl (8) pour agir par défaut sur le travail à partir duquel les commandes sont appelées.

       env KEY [= VALUE]
              Définit une variable d'environnement par défaut, dont la valeur peut être remplacée par l'événement ou la commande qui démarre le travail.
              Si «KEY = VALUE» est spécifié, la variable KEY reçoit la valeur VALUE. Si seulement «KEY» est donné, alors la valeur est prise
              depuis le propre environnement du démon init (8).

       export KEY
              Exporte la valeur d'une variable d'environnement dans les événements de démarrage (7), démarré (7), d'arrêt (7) et arrêté (7) pour cette
              travail et à tous les événements qui en résultent (pas seulement ceux liés au travail en cours).

De plus, vous pouvez faire grep env /etc/init/*pour voir comment est utilisé

Voici ma sortie:

/etc/init/container-detect.conf:env container
/etc/init/container-detect.conf:env LIBVIRT_LXC_UUID
/etc/init/container-detect.conf: # consiste à rechercher le "conteneur" dans l'environnement d'init.
/etc/init/container-detect.conf: [-d / proc / vz] && [! -d / proc / bc] && container = openvz
/etc/init/mounted-debugfs.conf:env MOUNTPOINT = / sys / kernel / debug
/etc/init/mounted-dev.conf:env MOUNTPOINT = / dev
/etc/init/mounted-proc.conf:env MOUNTPOINT = / proc
/etc/init/mounted-tmp.conf:env MOUNTPOINT = / tmp
/etc/init/munin-node.conf:env DAEMON = / usr / sbin / munin-node
/etc/init/mysql.conf:env HOME = / etc / mysql
/etc/init/nginx.conf:env DAEMON = / usr / local / nginx / sbin / nginx
/etc/init/nginx.conf:env PID = / usr / local / nginx / logs / nginx.pid
/etc/init/procps.conf:env UPSTART_EVENTS =
/etc/init/rc.conf:env INIT_VERBOSE
/etc/init/rc-sysinit.conf:env DEFAULT_RUNLEVEL = 2
/etc/init/rc-sysinit.conf:env RUNLEVEL =
/etc/init/rc-sysinit.conf:env PREVLEVEL =
/etc/init/rc-sysinit.conf:env INIT_VERBOSE
/etc/init/wait-for-state.conf:env TIMEOUT = 30
/etc/init/wait-for-state.conf:env MANUAL_OVERRIDE = "N"
/etc/init/wait-for-state.conf:env WAIT_FOREVER = "N"
/etc/init/wait-for-state.conf:env WAIT_STATE = "commencé"
/etc/init/wait-for-state.conf:env TARGET_GOAL = "start"

Et pour un exemple exhaustif, voyez certains de ces scripts. Voici nginx.conf:

# nginx

description "démon http nginx"
auteur "Philipp Klose"

démarrer (système de fichiers et net-device-up IFACE = lo)
arrêter au niveau d'exécution [! 2345]

env DAEMON = / usr / local / nginx / sbin / nginx
env PID = / usr / local / nginx / logs / nginx.pid

attendre une fourchette
respawn
limite de réapparition 10 5
#oom jamais

script de pré-démarrage
 $ DAEMON -t
 si [$? -ne 0]
 puis quittez $?
 Fi
script de fin

exec $ DAEMON
jperelli
la source