21 votes

Comment ajouter ~/bin à PATH pour un service systemd ?

J'ai un service systemd qui appelle un script PHP script qui crée un fichier tmux au démarrage.

Globalement, je dispose des informations les plus récentes tmux pour la distro (V>=2.5).
La fonction script de la fonction USER a une $HOME/bin/tmux de 2.0

Ce dont j'ai besoin, c'est de ceci systemd pour utiliser le tmux dans le $HOME de l'utilisateur.
J'ai défini les variables USER & GROUP dans le fichier de service systemd mais il semble appeler le binaire installé globalement.

Est-il possible de définir explicitement le binaire qui doit être appelé pour cette invocation de service ?

Si possible, je préférerais ne pas avoir à coder en dur le chemin dans le fichier PHP lui-même.

Merci beaucoup.

15voto

muru Points 180007

Vous pourriez coder en dur le PATH dans le service systemd :

[Service]
Environment=PATH=/home/someUser/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

Le système PAM serait plus souple. Il est terriblement détourné par rapport à l'utilisation simple de bash -c '....' mais vous pouvez le faire avec PAM.

Créer une nouvelle configuration PAM dans /etc/pam.d (dire /etc/pam.d/foo ) et ajouter :

session    required     pam_env.so user_envfile=some-file user_readenv=1

Et en /home/someUser/some-file , ajouter :

PATH DEFAULT=/home/someUser/bin:${PATH}

Bien entendu, vous pouvez ajuster la some-file à quelque chose de plus sensé, mais le chemin d'accès dans user_envfile doit être relative au répertoire personnel de l'utilisateur (l'utilisateur que vous avez défini dans la section User= dans le service).

Ensuite, dans le fichier de service, dans le champ [Service] ajouter ( foo étant le fichier dans /etc/pam.d créé précédemment) :

PAMName=foo

Maintenant, lorsque vous démarrez le service (après l'avoir rechargé, etc.), l'élément session modules en /etc/pam.d/foo sera exécuté, ce qui dans ce cas est juste pam_env . pam_env chargera les variables d'environnement de /etc/environment sous réserve de contraintes en /etc/security/pam_env.conf puis l'environnement de l'utilisateur à partir de ~/some-file . Depuis le PATH est fixé à une valeur par défaut dans /etc/environment l'environnement de l'utilisateur ajoute à cette valeur par défaut.

Ici, la valeur par défaut de user_envfile est .pam_environment qui est également lu par la configuration PAM d'autres éléments tels que la connexion SSH ou LightDM, etc. J'ai utilisé un fichier différent ici au cas où vous ne voudriez pas affecter ces choses. Vous pouvez supprimer le fichier user_envfile=... et utiliser la valeur par défaut ~/.pam_environment . vous pouvez également utiliser une configuration PAM existante dans /etc/pam.d qui a user_readenv=1 mais d'autres modules PAM peuvent provoquer des effets secondaires indésirables.

5voto

Mark Points 1274

Cela peut paraître terriblement artificiel, mais le fait de faire précéder le nom d'un $PATH La mise à jour semble fonctionner.
Je suis à l'affût d'effets secondaires cependant .

Ejemplo:

ExecStart=/bin/bash -c "PATH=/home/someUser/bin:$PATH exec /usr/bin/php /some/path/to/a/script.php"

4voto

Merlin Points 51

Je sais que je déterre un post qui date un peu, mais j'essayais moi aussi de comprendre comment je pouvais configurer les variables PATH/environnement pour que le planificateur s'exécute automatiquement lorsque le serveur est en cours d'exécution.

J'ai trouvé une solution qui fonctionne pour moi sur Ubuntu 18.04 et 18.10.

J'ai fourni une description complète de la façon de installer Airflow et PostgreSQL sur le backend sur le lien ici .

**Extrait de la suite de mon article Il s'agit essentiellement d'apporter une modification spécifique au fichier airflow-scheduler.system.

C'est l'un des "gotchas" pour une implémentation sur Ubuntu. L'équipe de développement qui a créé Airflow l'a conçu pour fonctionner sur une distribution linux différente et il y a donc un petit (mais critique) changement qui doit être fait pour qu'Airflow s'exécute automatiquement lorsque le serveur est allumé. Les fichiers de service systemd par défaut ressemblent initialement à ceci :

[Unit]
Description=Airflow scheduler daemon
After=network.target postgresql.service mysql.service redis.service rabbitmq-server.service
Wants=postgresql.service mysql.service redis.service rabbitmq-server.service

[Service]
EnvironmentFile=/etc/sysconfig/airflow
User=airflow
Group=airflow
Type=simple
ExecStart=/bin/airflow scheduler
Restart=always
RestartSec=5s

[Install]
WantedBy=multi-user.target

Cependant, cela ne fonctionnera pas car le protocole 'EnvironmentFile' ne fonctionne pas sur Ubuntu 18. A la place, commentez cette ligne et ajoutez :

Environment="PATH=/home/ubuntu/anaconda3/envs/airflow/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

Vous voudrez probablement créer un fichier de service systemd au moins pour l'Airflow Scheduler et probablement aussi pour le Webserver si vous voulez que l'interface utilisateur se lance automatiquement. En effet, nous voulons les deux dans cette implémentation, nous allons donc créer deux fichiers, airflow-scheduler.service & airflow-webserver.service. Ces deux fichiers seront copiés dans le dossier /etc/systemd/system. Ces fichiers sont les suivants :


airflow-scheduler.service

[Unit]
Description=Airflow scheduler daemon
After=network.target postgresql.service mysql.service redis.service rabbitmq-server.service
Wants=postgresql.service mysql.service redis.service rabbitmq-server.service

[Service]
#EnvironmentFile=/etc/default/airflow
Environment="PATH=/home/ubuntu/anaconda3/envs/airflow/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
User=airflow
Group=airflow
Type=simple
ExecStart=/home/ubuntu/anaconda3/envs/airflow/bin/airflow scheduler
Restart=always
RestartSec=5s

[Install]
WantedBy=multi-user.target
#airflow-webserver.service

airflow-webserver.service

[Unit]
Description=Airflow webserver daemon
After=network.target postgresql.service mysql.service redis.service rabbitmq-server.service
Wants=postgresql.service mysql.service redis.service rabbitmq-server.service

[Service]
#EnvironmentFile=/etc/default/airflow
Environment="PATH=/home/ubuntu/anaconda3/envs/airflow/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
User=airflow
Group=airflow
Type=simple
ExecStart=/home/ubuntu/anaconda3/envs/airflow/bin/airflow webserver -p 8085 --pid /home/ubuntu/airflow/airflow-webserver.pid
Restart=on-failure
RestartSec=5s
PrivateTmp=true

[Install]
WantedBy=multi-user.target

Enfin, ces deux fichiers ayant été copiés dans le dossier /etc/systemd/systemd à l'aide de la commande de copie sudo cp du superutilisateur, il est temps de mettre le contact :

sudo systemctl enable airflow-scheduler sudo systemctl start airflow-scheduler sudo systemctl enable airflow-webserver sudo systemctl start airflow-webserver

2voto

Pandakaebi Points 29

Dans un service que je mettais en place (Apache Airflow), j'avais défini un fichier d'environnement.

Dans mon /etc/systemd/system/airflow j'avais cette ligne :

[Service]
EnvironmentFile=/etc/default/airflow

En ouvrant ce fichier d'environnement, j'ai ajouté la ligne dont j'avais besoin, dans mon cas :

SCHEDULER_RUNS=5
PATH=/opt/anaconda3/bin:$PATH

Ajoutez les chemins d'accès aux exécutables dont vous avez besoin pour que le service puisse les atteindre ici et vous devriez être en mesure de le faire. Cela a bien fonctionné pour moi.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X