systemd (Français)/User (Français)
Systemd offre la possibilité de gérer des services sous le contrôle de l'utilisateur en lui permettant de démarrer, arrêter, activer ou désactiver une unité utilisateur. Cette option est pratique pour les daemons et autres services qui ne sont généralement exécutés que pour un seul utilisateur, comme mpd, ou pour effectuer des tâches automatisées comme la récupération du courrier électronique.
Fonctionnement
Selon la configuration par défaut dans /etc/pam.d/system-login, le module pam_systemd lance automatiquement une instance systemd --user lorsque l'utilisateur se connecte pour la première fois. Ce processus survivra tant qu'il y aura une session pour cet utilisateur, et sera tué dès que la dernière session de l'utilisateur sera fermée. Lorsque #Démarrage automatique des instances utilisateur systemd est activé, l'instance est démarrée au démarrage et ne sera pas tuée. L'instance utilisateur systemd est responsable de la gestion des services utilisateurs, qui peuvent être utilisés pour exécuter des daemons ou des tâches automatisées, avec tous les avantages de systemd, tels que l'activation des sockets, les timers, le système de dépendances ou le contrôle strict des processus via les cgroups.
De la même manière que les unités système, les unités utilisateur sont situées dans les répertoires suivants (classés par ordre de préséance ascendante) :
/usr/lib/systemd/user/où appartiennent les unités fournies par les paquets installés.- où appartiennent les unités des paquets qui ont été installés dans le répertoire personnel.
- où sont placées les unités des utilisateurs du système par l'administrateur système.
- où l'utilisateur place ses propres unités.
Lorsqu'une instance utilisateur de systemd démarre, elle active la cible par utilisateur . Les autres unités peuvent être contrôlées manuellement avec systemctl --user. Consultez systemd.special(7) § UNITS MANAGED BY THE USER SERVICE MANAGER.
Configuration de base
Toutes les unités de l'utilisateur seront placées dans . Si vous voulez démarrer les unités à la première connexion, exécutez pour toute unité que vous voulez démarrer automatiquement.
Variables d'environnement
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 :
- 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.
- Utiliser l'option dans le fichier
/etc/systemd/user.conf. Affecte toutes les unités utilisateur. - Ajouter un fichier de configuration de dépôt dans
/etc/systemd/system/user@.service.d/. Affecte toutes les unités utilisateur ; consultez #Exemple de service. - 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.
- 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.
- 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.
- Vous pouvez également écrire un script 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 .
Après la configuration, la commande systemctl --user show-environment peut être utilisée pour vérifier que les valeurs sont correctes.
Exemple de service
Créez le répertoire «drop-in» /etc/systemd/system/user@.service.d/ et créez à l'intérieur un fichier ayant l'extension .conf (par exemple ) :
DISPLAY et XAUTHORITY
DISPLAY 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 DISPLAY et .
PATH
Si vous personnalisez votre et prévoyez de lancer des applications qui l'utilisent à partir d'unités systemd, vous devez vous assurer que le modifié est défini dans l'environnement systemd. En supposant que vous avez défini votre dans , la meilleure façon de faire connaître à systemd votre modifié est d'ajouter ce qui suit à après la définition de la variable :
pam_env
Les variables d'environnement peuvent être rendues disponibles par l'utilisation du module pam_env.so. Consultez Environment variables#Using pam_env pour les détails de configuration.
Démarrage automatique des instances utilisateur systemd
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
Écrire des unités utilisateur
Consultez Systemd (Français)#Écrire des unités pour des informations générales sur l'écriture des fichiers d'unités de systemd.
Exemple
Voici un exemple d'une version utilisateur du service mpd :
Exemple avec variables
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.
Lecture du journal
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
Fichiers temporaires
systemd-tmpfiles permet aux utilisateurs de gérer des fichiers et des répertoires volatils et temporaires personnalisés, tout comme pour le système dans son ensemble (consultez Systemd (Français)#systemd-tmpfiles - fichiers temporaires). Les fichiers de configuration spécifiques à l'utilisateur sont lus dans ~/.config/user-tmpfiles.d/ et , dans cet ordre. Pour que cette fonctionnalité puisse être utilisée, il est nécessaire d'activer les unités utilisateur systemd nécessaires pour votre utilisateur :
$ systemctl --user enable systemd-tmpfiles-setup.service systemd-tmpfiles-clean.timer
La syntaxe des fichiers de configuration est la même que celle utilisée dans tout le système. Consultez les pages de manuel systemd-tmpfiles(8) et pour plus de détails.
Xorg et systemd
Il y a plusieurs façons d'exécuter xorg dans les unités systemd. Ci-dessous, il y a deux options, soit en démarrant une nouvelle session utilisateur avec un processus xorg, soit en lançant xorg depuis un service utilisateur systemd.
Connexion automatique à Xorg sans gestionnaire d'affichage
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 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.
Xorg comme service utilisateur systemd
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).
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 /etc/X11/Xwrapper.config. Ceci s'appuie sur Xorg (Français)#Xorg en root en ajoutant la stipulation que cela n'a pas besoin d'être fait depuis une console physique. C'est-à-dire que le défaut de de console est remplacé par ; voir .
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 DISPLAY 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 , 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 .
Quelques cas d'utilisation
Gestionnaire de fenêtres
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 :
~/.config/systemd/user/awesome.service
[Unit] Description=Awesome window manager After=xorg.target Requires=xorg.target [Service] ExecStart=/usr/bin/awesome Restart=always RestartSec=10 [Install] WantedBy=wm.target
Multiplexeur de terminal persistant
Plutôt que de vous connecter par défaut à une session de gestionnaire de fenêtres pour votre session utilisateur, vous pouvez souhaiter exécuter automatiquement un multiplexeur de terminal (tel que screen ou tmux) en arrière-plan.
Créez ce qui suit :
Séparer le login du login X n'est probablement utile que pour ceux qui démarrent sur un TTY au lieu d'un gestionnaire d'affichage (dans ce cas, vous pouvez simplement regrouper tout ce que vous démarrez dans ).
La dépendance , comme la ci-dessus, permet de démarrer tout ce qui doit être exécuté avant le démarrage du multiplexeur (ou que vous voulez démarrer au démarrage sans tenir compte du timing), comme une session du démon 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 . Cette session d'exemple, lorsque vous démarrez X, sera également capable d'exécuter des programmes X, puisque est défini :
~/.config/systemd/user/tmux.service
[Unit] Description=tmux: A terminal multiplexer Documentation=man:tmux(1) After=gpg-agent.service Wants=gpg-agent.service [Service] Type=forking ExecStart=/usr/bin/tmux start ExecStop=/usr/bin/tmux kill-server Environment=DISPLAY=:0 EnvironmentFile=/tmp/gpg-agent-info [Install] WantedBy=multiplexer.target
Activez , et tous les services que vous avez créés pour être exécutés par , démarrez comme d'habitude et vous devriez avoir terminé.
Tuer les processus utilisateur lors de la déconnexion
Arch Linux construit le paquet avec , définissant à no par défaut. Ce paramètre fait que les processus utilisateur ne sont pas tués lorsque l'utilisateur se déconnecte. Pour modifier ce comportement afin que tous les processus utilisateur soient tués lors de la déconnexion de l'utilisateur, définissez dans .
Notez que la modification de ce paramètre casse les multiplexeurs de terminaux tels que tmux et GNU Screen. Si vous modifiez ce paramètre, vous pouvez toujours utiliser un multiplexeur de terminal en utilisant systemd-run comme suit :
$ systemd-run --scope --user command args.
Par exemple, pour exécuter vous devez faire :
$ systemd-run --scope --user screen -S foo
L'utilisation de systemd-run ne maintiendra le processus en cours d'exécution après la déconnexion que si l'utilisateur est connecté au moins une fois ailleurs dans le système et que est toujours en cours d'exécution.
Après que l'utilisateur se soit déconnecté de toutes les sessions, sera également arrêté, par défaut, à moins que l'utilisateur n'ait activé la fonction "lingering" . Pour permettre aux utilisateurs d'exécuter des tâches à long terme même s'ils sont complètement déconnectés, la fonction "lingering" doit être activée pour eux. Consultez #Démarrage automatique des instances utilisateur systemd et pour plus de détails.
Dépannage
Runtime directory '/run/user/1000' is not owned by UID 1000, as it should
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 répertoire. Cela peut se produire par exemple si vous utilisez un conteneur docker qui a un montage bind sur . Pour résoudre ce problème, vous pouvez soit réparer le conteneur en supprimant le montage, soit désactiver/retarder le service docker.
Voir aussi
- Le wiki Bitbucket de KaiSforza
- Les unités de Zoqaeski sur GitHub
- Fil du forum Arch sur les changements dans les instances utilisateur de systemd 206