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

From ArchWiki
< Systemd (Français)
Jump to navigation Jump to search
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.

Related articles

- systemd
- Automatic login to virtual console
- Start X at login

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é.

## 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

Category:

- System administration (Français)