systemd (Français)/User (Français)

L'instance utilisateur de systemd n'hérite d'aucune des variables d'environnement définies dans des endroits comme , etc. Il existe plusieurs façons de définir les variables d'environnement pour l'instance utilisateur de systemd :

1. Pour les utilisateurs ayant un répertoire , créez un fichier .conf dans le répertoire avec des lignes de la forme . Affecte uniquement l'unité utilisateur de cet utilisateur. Consultez pour plus d'informations.
2. Utiliser l'option dans le fichier /etc/systemd/user.conf. Affecte toutes les unités utilisateur.
3. Ajouter un fichier de configuration de dépôt dans . Affecte toutes les unités utilisateur ; consultez #Exemple de service.
4. A tout moment, utilisez ou . Affecte toutes les unités utilisateur démarrées après la définition des variables d'environnement, mais pas les unités qui étaient déjà en cours d'exécution.
5. Utiliser la commande fournie par dbus. A le même effet que , mais affecte également la session D-Bus. Vous pouvez ajouter ceci à la fin de votre fichier d'initialisation du shell.
6. Pour les variables d'environnement "globales" pour l'environnement de l'utilisateur, vous pouvez utiliser les répertoires qui sont analysés par certains générateurs. Consultez et pour plus d'informations.
7. Vous pouvez également écrire un script systemd.environment-generator(7) qui peut produire des variables d'environnement qui varient d'un utilisateur à l'autre, c'est probablement la meilleure façon si vous avez besoin d'environnements par utilisateur (c'est le cas pour , , etc).

Une variable que vous pouvez vouloir définir est PATH.

Après la configuration, la commande peut être utilisée pour vérifier que les valeurs sont correctes.

Créez le répertoire «drop-in» et créez à l'intérieur un fichier ayant l'extension .conf (par exemple ) :

est utilisé par toute application X pour savoir quel affichage utiliser et  pour fournir un chemin vers le fichier  de l'utilisateur et donc le cookie nécessaire pour accéder au serveur X. Si vous prévoyez de lancer des applications X à partir d'unités systemd, ces variables doivent être définies. Systemd fournit un script dans  pour importer ces variables dans la session de l'utilisateur systemd au lancement de l'application.  Donc, à moins que vous ne démarriez X d'une manière non standard, les services utilisateurs devraient être conscients des variables  et .

Si vous personnalisez votre PATH et prévoyez de lancer des applications qui l'utilisent à partir d'unités systemd, vous devez vous assurer que le PATH modifié est défini dans l'environnement systemd. En supposant que vous avez défini votre PATH dans .bash_profile, la meilleure façon de faire connaître à systemd votre PATH modifié est d'ajouter ce qui suit à .bash_profile après la définition de la variable PATH :

Les variables d'environnement peuvent être rendues disponibles par l'utilisation du module . Consultez Environment variables#Using pam_env pour les détails de configuration.

L'instance utilisateur systemd est démarrée après la première connexion d'un utilisateur et tuée après la fermeture de la dernière session de l'utilisateur. Parfois, il peut être utile de la lancer juste après le démarrage, et de maintenir l'instance utilisateur systemd en cours d'exécution après la fermeture de la dernière session, par exemple pour avoir un processus utilisateur en cours d'exécution sans aucune session ouverte. Lingering est utilisé à cet effet. Utilisez la commande suivante pour activer le lingering pour un utilisateur spécifique :

# loginctl enable-linger username

Voici un exemple d'une version utilisateur du service mpd :

Ci-dessous, le service utilisateur de , qui tient compte par une variable des répertoires personnels où Folding@home peut trouver certains fichiers :

Comme détaillé dans , la variable est remplacée par le répertoire personnel de l'utilisateur qui exécute le service. Il existe d'autres variables qui peuvent être prises en compte dans les pages de manuel de systemd.

Le journal de l'utilisateur peut être lu en utilisant la commande analogue :

$ journalctl --user

Pour spécifier une unité, on peut utiliser

$ journalctl --user-unit monunité.service

Ou, de manière équivalente

$ journalctl --user -u monunité.service

Cette option lancera une unité système qui démarrera une session utilisateur avec un serveur xorg, puis exécutera les habituels pour lancer le gestionnaire de fenêtres, etc. Vous devez avoir installé . Configurez votre xinitrc comme indiqué dans la section Xinit (Français)#xinitrc.

La session utilisera son propre daemon dbus, mais divers utilitaires systemd se connecteront automatiquement à l'instance . Enfin, activez le service xlogin@username pour une connexion automatique au démarrage. La session utilisateur vit entièrement à l'intérieur d'un scope systemd et tout ce qui se trouve dans la session utilisateur devrait fonctionner parfaitement.

Alternativement, xorg peut être exécuté à partir d'un service utilisateur systemd. C'est une bonne chose puisque d'autres unités liées à X peuvent être rendues dépendantes de xorg, etc, mais d'un autre côté, cela a quelques inconvénients expliqués ci-dessous.

fournit une intégration avec systemd de deux manières :

• Il peut être exécuté sans privilège, déléguant la gestion des périphériques à logind (consultez les commits de Hans de Goede autour de ce commit).
• Peut être transformé en un service activé par socket (consultez ce commit). Cela supprime le besoin de .

Malheureusement, pour pouvoir exécuter xorg en mode non privilégié, il doit être exécuté dans une session. Donc, actuellement, le handicap de l'exécution de xorg en tant que service utilisateur est qu'il doit être exécuté avec les privilèges root (comme avant la 1.16), et ne peut pas profiter du mode non privilégié introduit dans la 1.16.

Voici comment lancer xorg à partir d'un service utilisateur :

1. Faites tourner xorg avec les privilèges root pour n'importe quel utilisateur, en éditant .

2. Ajoutez les unités suivantes à

où est le terminal virtuel où xorg sera lancé, soit codé en dur dans l'unité de service, soit défini dans l'environnement systemd avec

$ systemctl --user set-environment XDG_VTNR=1

3. Assurez-vous de configurer la variable d'environnement comme expliqué ci-dessus.

4. Ensuite, pour activer l'activation de la socket pour xorg sur l'affichage 0 et le tty 2, il faut faire :

$ systemctl --user set-environment XDG_VTNR=2 # Pour que xorg@.service sache quel vt utiliser
$ systemctl --user start xorg@0.socket # Commence à écouter sur le socket pour l'affichage 0

Maintenant, l'exécution de toute application X lancera xorg sur le terminal virtuel 2 automatiquement.

La variable d'environnement XDG_VTNR peut être définie dans l'environnement systemd à partir de .bash_profile, et l'on peut alors démarrer n'importe quelle application X, y compris un gestionnaire de fenêtres, en tant qu'unité systemd qui dépend de .

Avec une version adaptée de , on peut facilement faire fonctionner tous les clients X en tant que service utilisateur tout en laissant Xorg, le serveur, fonctionner dans une session non privilégiée.

Premièrement, mettez une copie de sous . La copie peut être nommée par exemple sdsx afin que l'original reste accessible.

Ensuite, remplacez

trap 'DISPLAY=:$tty exec "${@:-$cfgdir/sxrc}" & wait "$ !" USR1

par

trap 'systemd-run --user -u sx-client-$tty -E DISPLAY=:$tty -E XAUTHORITY="$XAUTHORITY" \
      "${@:-$cfgdir/sxrc}" & wait "$pid"' USR1

et remplacez

(trap '' USR1 && exec Xorg : "$tty" -keeptty vt "$tty" -noreset -auth "$XAUTHORITY") & pid=$!

avec

(trap '' USR1 && exec Xorg :"$tty" -keeptty vt"$tty" -terminate -auth "$XAUTHORITY") & pid=$!

L'inconvénient de cette approche est que, si pour une raison quelconque, aucun client X n'a réussi à atteindre le serveur, le serveur devra être tué manuellement à partir d'un autre tty. De plus, si, par exemple, doit être exécuté dans , il devra maintenant être exécuté avec l'option . Consultez Xserver(1) et pour plus de détails.

L'un des cas d'utilisation et/ou des avantages de cette approche est que les clients X seront désormais exécutés sous le gestionnaire d'utilisateurs () et que le snippet (c'est-à-dire ) qui lui est appliqué (par exemple, ) sera également appliqué aux programmes exécutés dans l'environnement graphique (y compris, mais sans s'y limiter, les shells de ligne de commande exécutés dans un émulateur de terminal).

Pour exécuter un gestionnaire de fenêtres en tant que service systemd, vous devez d'abord exécuter #Xorg comme service utilisateur systemd. Dans ce qui suit, nous utiliserons awesome comme exemple :

Vous pouvez souhaiter que votre session utilisateur exécute par défaut un multiplexeur de terminal, tel que GNU Screen ou Tmux, en arrière-plan plutôt que de vous connecter à une session de gestionnaire de fenêtres. Séparer la connexion de la connexion à X n'est probablement utile que pour ceux qui démarrent sur un TTY plutôt que sur un gestionnaire d'affichage (dans ce cas, vous pouvez simplement regrouper tout ce que vous démarrez avec ).

Pour créer ce type de session utilisateur, procédez comme ci-dessus, mais au lieu de créer , créez  :

, comme ci-dessus, devrait démarrer tout ce que vous pensez devoir être exécuté avant le démarrage de tmux ou de screen (ou que vous voulez démarrer au démarrage sans tenir compte du moment), comme une session du daemon GnuPG.

Vous devez ensuite créer un service pour votre session multiplexeur. Voici un exemple de service, utilisant tmux comme exemple et utilisant une session gpg-agent qui écrit ses informations dans /tmp/gpg-agent-info. Cette session d'exemple, lorsque vous démarrez X, sera également capable d'exécuter des programmes X, puisque DISPLAY est défini.

Une fois que c'est fait, activez , et tous les services que vous avez créés pour être exécutés par et vous devriez être prêt à partir ! Démarrez comme d'habitude. Félicitations ! Vous avez un multiplexeur de terminal en fonctionnement et quelques autres programmes utiles prêts à être lancés au démarrage !

systemd[1867]: pam_systemd(systemd-user:session): Runtime directory '/run/user/1000' is not owned by UID 1000, as it should.
systemd[1867]: Trying to run as user instance, but $XDG_RUNTIME_DIR is not set

Si vous consultez des erreurs de ce type et que votre session de connexion est interrompue, il est possible qu'un autre service système (non utilisateur) sur votre système crée ce dossier. Cela peut se produire par exemple si vous utilisez un conteneur docker qui a un montage bind sur /run/user/1000. Pour résoudre ce problème, vous pouvez soit réparer le conteneur en supprimant le montage, soit désactiver/retarder le service docker.