Comment configurer un service systemd devant être lancé par un utilisateur non root en tant que démon utilisateur?

Je viens de terminer le processus d'installation et de configuration de systemd sur mon système arch-linux (2012.09.07). J'ai désinstallé initscripts(et supprimé les fichiers de configuration).

Ce que je veux faire, c'est créer un service qui puisse être démarré et arrêté par un utilisateur non root. Le service doit démarrer une session d'écran séparée exécutant rtorrent. Cependant, je souhaite que chaque utilisateur du système qui a configuré ce service pour qu'il démarre (activé) ait une instance particulière démarrée spécifiquement pour eux. Comment pourrait-on s'y prendre?

Je me souviens avoir lu que systemd prenait en charge les instances d'utilisateurs de services, mais je n'ai trouvé aucune information sur la manière de configurer cela, ni de savoir si cela se rapportait à ce que je cherchais.

Fichier de service que j'ai utilisé pour le système:

[Unit]
Description=rTorrent

[Service]
Type=forking
ExecStart=/usr/bin/screen -d -m -S rtorrent /usr/bin/rtorrent
ExecStop=/usr/bin/killall -w -s 2 /usr/bin/rtorrent

MISE À JOUR # 1 :

Après avoir lu les pages de manuel ici et ici , je comprends comment systemd fonctionne un peu mieux. Plus précisément, l'utilisation des options User=et WorkingDirectory=permet de démarrer le service dans la session d'un utilisateur. Cependant , la question reste pas moins que l'utilisateur ne peuvent pas eux - mêmes start, stop, enableou disablele service. Une erreur d' accès est refusée est donnée par systemctl.

MISE À JOUR # 2 :

Tout d'abord, pour simplifier et utiliser au mieux la fonctionnalité de session utilisateur de systemd (encore un peu incomplète), j'ai utilisé les unités de session utilisateur de sofar et suivi ses conseils de configuration.

Il semble qu'il y ait un bogue dans la version actuelle de DBus (1.6.4-1) dans lequel il est impossible de définir la variable d'environnement, DBUS_SESSION_BUS_ADDRESSce qui signifie que la systemctl --usercommande error out est exécutée avec:

Failed to get D-Bus connection: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11

La variable devrait ressembler à ceci:

DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/USERUID/dbus/user_bus_socket"

où USERUID doit être l'UID de l'utilisateur donné.

— Hans
source

Je me rends compte que l'on pourrait créer un fichier de service distinct par utilisateur et l'activer simplement. Cependant, je veux juste savoir si cela pourrait être possible comme je l’ai décrit ci-dessus.

— Hans

Très bien, je pouvais configurer simplement sudoles utilisateurs et les laisser, comme mentionné dans mon commentaire ci-dessus, contrôler leur propre fichier de service. Cependant, cette solution permettrait également à l'utilisateur de contrôler la plupart des autres services ...

— Hans,

Si vous aviez lu sudola documentation , cela ne serait pas le cas - sudoers (5) contient de nombreux exemples de restriction des arguments d'une commande.

— Grawity

Normalement, systemd n'autorise pas les utilisateurs ordinaires à démarrer les services système. Bien qu'il prenne en charge l'accès via polkit, cette partie manque encore quelque peu et vous ne pouvez pas encore autoriser un seul service spécifique.

Puisque rtorrent n’est pas réellement un service système et que vous voulez que chaque utilisateur ait sa propre instance de rtorrent, testez le mode "utilisateur" de systemd.

Lorsque vous vous connectez, le système démarrera une user@<uid>.serviceunité centrale pour vous, qui lancera une instance distincte "--user" de systemd. Le nouvel utilisateur-systemd lira les fichiers d'unité (en commençant par default.target) à partir de ~/.config/systemd/user/, /etc/systemd/user/et /usr/lib/systemd/user/.

— Grawity
source

Merci Grawity, c'est essentiellement ce qui me manquait. Cependant, il s’avère également un problème DBus: il semble y avoir un bogue dans dbuse qui ne définit pas la variable globale correcte DBUS_SESSION_BUS_ADDRESSpour un utilisateur donné, si bien que systemctl ne peut pas accéder à la session utilisateur, il y a une erreur. Une fois que j'ai compris ce petit problème, tout le reste fonctionne à merveille!

— Hans