Puis-je contrôler un systemd utilisateur en utilisant ‘systemctl –user’ après sudo su – myuser?

J’ai un service que je veux commencer avec le démarrage du système. J’ai créé une définition ap @ .service en tant que modèle, car il pourrait y avoir de nombreuses instances.

Défini dans la racine systemd, cela fonctionne bien et démarre et arrête le service avec le système. L’instance de service est installée avec systemctl enable ap@inst1 comme prévu. Root est également capable de démarrer et d’arrêter le service sans problèmes. Le service s’exécute dans son propre compte (myuser), pas root, contrôlé par User = myuser dans le modèle ap @ .service.

Mais je veux que l’utilisateur «myuser» puisse démarrer et arrêter son propre service sans compromettre la sécurité du système.

Je suis passé à l’utilisation d’un système utilisateur, et loginctl enable-linger myuser permis de loginctl enable-linger myuser avec loginctl enable-linger myuser . J’active ensuite le service défini dans le répertoire ~ myuser / .config / systemd / user. Le service démarre et s’arrête maintenant correctement avec le système, comme prévu. Si je me connecte à un terminal en tant que «myuser», systemctl --user start ap@inst1 , et systemctl --user stop ap@inst1 fonctionnent tous deux parfaitement.

Cependant, si je me connecte en tant qu’utilisateur différent (user2) et exécute sudo su - myuser dans un terminal, les commandes systemctl --user échouent alors avec le message d’erreur “Impossible d’obtenir la connexion D-Bus: pas de fichier ou répertoire”.

Comment puis-je activer systemctl --user après une commande sudo su - myuser pour changer d’utilisateur?

J’ai trouvé la réponse sur un autre site avec d’autres recherches utilisant des termes différents.

Les solutions nécessaires consistaient à fournir au shell des informations permettant d’atteindre le bon DBUS pour l’utilisateur.

En ajoutant les variables d’environnement suivantes au shell avant d’exécuter systemctl --user , le problème DBUS est éliminé et systemctl fonctionne correctement.

 export XDG_RUNTIME_DIR="/run/user/$UID" export DBUS_SESSION_BUS_ADDRESS="unix:path=${XDG_RUNTIME_DIR}/bus"

Pour vous assurer que DBUS_SESSION_BUS_ADDRESS est disponible dans le shell sudo, j’ai ajouté les variables d’environnement à ~ / .bash_profile de l’ID utilisateur cible. Cela nécessite qu’un shell de connexion ( sudo su - myuser ou sudo -l myuser ) soit créé afin de créer l’environnement correct.

Vous pouvez également append la création des variables d’environnement à ~ / .bashrc (ou l’équivalent pour les autres shells). L’environnement sera alors établi à nouveau pour toutes les créations de shells.