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

The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

Cet article ou section a besoin d'être traduit(e).

Notes: Cet article ne respecte pas la structure de sa version anglophone, merci de le réécrire en conséquence. Vous pouvez aussi ajouter à la version anglophone les informations à-jour et dignes d’intérêt qui ne seraient portées que par la version francophone. Voir Archwiki:Translation_Team_(Français) (Discuss in Talk:Systemd (Français)/User (Français)#)

Systemd offre la possibilité d'utiliser des unités dans l'espace de l'utilisateur en lui permettant de démarrer, d'arrêter, d'activer ou de désactiver une unité. Cette option est utile pour les démons et autres services qui sont généralement exécutés pour un seul utilisateur, comme mpd, ou pour effectuer des tâches automatisées comme la récupération du courrier électronique.

Fonctionnement

Après le démarrage de la session d'un utilisateur, systemd démarre automatiquement une instance systemd --user qui gère les services et les unités de l'utilisateur. Les unités restent actives tant que la session de l'utilisateur demeure active et seront stoppées dès que la dernière session de l'utilisateur sera arrêtée. Par défaut, aucune unité dans l'espace utilisateur n'est active. Les services utilisateurs peuvent être utilisés par exemple pour des tâches automatisées et bénéficier du mécanisme de systemd comme l'activation de socket, timer, le système de dépendance, contrôle de processus à l'aide de cgroups, etc.

Les unités de l'utilisateur sont situées dans les répertoires suivants (ordonnés par ordre d'importance):

/usr/lib/systemd/user/ pour les unités fournis par des paquets.
/etc/systemd/user/ pour les unités systèmes installés par l'administrateur du système.
~/.config/systemd/user/ pour les unités de l'utilisateur.

Systemd démarre le target default.target et ensuite l'instance systemd peut être contrôlée manuellement à l'aide de:

systemctl --user

Systemd offre la possibilité d'utiliser des unités dans l'espace de l'utilisateur en leur permettant de démarrer, d'arrêter, d'activer ou de désactiver une unité. C'est pratique pour les services qui sont utilisés pour un seul utilisateur, tels que Music Player Daemon ou de réaliser des tâches automatisées telles que récupérer ses mails. En prenant certaines précautions, il est même possible de démarrer xorg et d'utiliser le gestionnaire de fenêtre en utilisant des services utilisateurs.

Mise en place

Une instance utilisateur de systemd doit être démarrée automatiquement lors du login. Pour contrôler que c'est le cas, vous pouvez utiliser:

systemctl --user status

Note: Si une instance utilisateur n'est pas démarrée automatiquement, contrôlez le fichier /etc/pam.d/system-login. Il devrait contenir une ligne semblable à

 -session optional pam_systemd.so

Contrôlez également si un fichier .pacnew existe.

Tous les services de l'utilisateur seront placés dans ~/.config/systemd/user.

D-Bus

Certains programmes, systemd inclus, ont besoin d'un bus utilisateur pour les messages dbus. Ceci est démarré normalement quand un environnement graphique est démarré à l'aide de dbus-launch. Toutefois si vous utilisez l'instance utilisateur systemd, il est souhaitable d'exécuter le serveur dbus comme un service systemd.

Note: Avec la transition à venir de systemd vers kdbus, systemd deviendra de toute façon le gestionnaire du bus des messages système et utilisateur.

Pour la mise en place:

1. Ajoutez un service et une unité socket pour le serveur dbus sous /etc/systemd/user

/etc/systemd/user/dbus.socket

[Unit]
Description=D-Bus Message Bus Socket
Before=sockets.target

[Socket]
ListenStream=%t/dbus/user_bus_socket

[Install]
WantedBy=default.target

/etc/systemd/user/dbus.service

[Unit]
Description=D-Bus Message Bus
Requires=dbus.socket

[Service]
ExecStart=/usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation
ExecReload=/usr/bin/dbus-send --print-reply --session --type=method_call --dest=org.freedesktop.DBus / org.freedesktop.DBus.ReloadConfig

2. La variable d'environnement DBUS_SESSION_BUS_ADDRESS doit contenir une valeur. Cela peut être réalisé en utilisant un fichier de configuration pour user@.service, en créant le fichier suivant:

/etc/systemd/system/user@.service.d/dbus.conf

[Service]
Environment=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/%I/dbus/user_bus_socket

3. Activez le socket pour tous les utilisateurs en tant que superutilisateur:

systemctl --global enable dbus.socket

Variables d'environnement

L' instance utilisateur de systemd n'hérite pas des variables d'environnements définies par exemple dans .bashrc, etc. Il y a deux manières d'attribuer des valeurs aux variables d'environnement pour l'instance systemd:

1. Ajoutez un fichier de configuration dans /etc/systemd/system/user@.service.d de la même manière que pour dbus. Cela rend la variable accessible pour l'instance utilisateur de systemd.

2. Quand vous le désirez, utilisez

systemctl --user set-environment

ou

systemctl --user import-environment

Toutes les unités démarrées après l'exécution de la commande obtiendront les valeurs des variables d'environnement, mais pas celles qui étaient déjà actives.

Les variables qui sont souhaitées sont DISPLAY ou PATH.

DISPLAY

DISPLAY est utilisé par les applications sous X pour savoir quel écran doit être utilisé. Si vous désirez démarrer des applications X d'unités systemd, vous devez donner une valeur à cette variable. Vous pouvez utiliser pour cela le fichier de configuration

/etc/systemd/system/user@.service.d/display.conf

[Service]
Environment=DISPLAY=:0

La valeur choisie ici de :0 est la valeur habituelle lorsqu'un seul serveur X est actif.

Note: Il est préférable d'attribuer la valeur de X à l'aide d'un fichier de configuration car ainsi elle sera accessible dès le départ. Si DISPLAY est mis plus tard, dbus.service n'aura certainement pas la valeur et à présent (jusqu'à ce que kdbus arrive) tous les services actifs qui ont besoins de DBUS, n'auront pas accès à la variable DISPLAY.

PATH

Tout comme d'autres variables d'environnement définies dans .bashrc ou .bash_profile, la variable PATH n'est pas accessible pour systemd. Si vous modifiez votre PATH et démarrez des applications qui l'utilisent depuis des unités systemd, vous devez vous assurer que le PATH modifié est défini dans l'environnement systemd. En supposant que PATH est défini dans .bash_profile, le meilleur moyen que systemd ait accès au PATH modifié est d'ajouter la ligne suivante au .bash_profile après la définition de PATH:

~/.bash_profile

systemctl --user import-environment PATH

Autres variables

Si vous avez besoin d'autres variables pour systemd, vous pouvez les définir dans .bashrc ou .bash_profile ou même dans un service systemd en utilisant une des commandes suivantes:

systemctl --user set-environment VARIABLE=valeur   # Attribue valeur à la variable VARIABLE
systemctl --user import-environment VARIABLE      # Importe VARIABLE de l'environnement appelant
systemctl --user import-environment               # Importe toutes les variables de l'environnement appelant

Démarrage automatique des instances utilisateur de systemd

L' instance utilisateur de systemd est démarrée après le login de l'utilisateur et arrêtée après que la dernière session de l'utilisateur est fermée. Parfois il est utile de la démarrer directement après le boot et de garder l'instance utilisateur de systemd active après que la dernière session a été fermée, par exemple pour avoir des processus utilisateurs actifs sans session active.

Note: Les services systemd ne sont pas des sessions, ils sont actifs en dehors de logind. N'utilisez pas la persistance pour activer un login automatique, car il stoppera la session

Utilisez la commande suivante pour activer la persistance pour un utilisateur particulier:

loginctl enable-linger username