systemctl –user

La littérature concernant systemctl est assez abondante en revanche pour systemctl --user on frôle le désert, un petit article ?

J’avais le désir de lancer mon émulateur de terminal Tilix au démarrage de ma session et qu’il se relance à chaque fois qu’il est fermé. Je commence à bien toucher les services systemd, systemctl mais là je me suis pris un four.

Le tiercé dans le bon ordre

Comme d’habitude ce n’est pas forcément compliqué, c’est juste qu’il faut le savoir. Pour mettre en place un service utilisateur systemd la difficulté ne se situe pas dans les lignes de commande mais davantage dans le bon ordre/enchaînement des commandes.

mkdir -p ~/.config/systemd/user
nano ~/.config/systemd/user/tilix.service
systemctl --user enable tilix.service # systemctl --user reenable tilix.service
systemctl --user start tilix.service # journalctl --user -u tilix -f

nano ~/.config/systemd/user/tilix.service
systemctl --user daemon-reload; systemctl --user restart tilix # systemctl --user --now enable tilix

Remarquez que nulle part il n’y a de sudo, vous n’avez besoin d’aucun droit root justement parce qu’on met en place un service utilisateur. Un service plus « classique » systemd comme on en met sur les serveurs par exemple aurait donné sudo systemctl enable joli.service.

On commence par créer le dossier qui va accueillir nos services utilisateur mkdir -p ~/.config/systemd/user. On crée/configure notre service nano ~/.config/systemd/user/tilix.service puis on l’active systemctl --user enable tilix.service donc à la prochaine ouverture de session de notre utilisateur, il sera lancé automatiquement. Maintenant on le démarre systemctl --user start tilix.service notamment pour voir si il fonctionne comme on le souhaite. En plus de ces commandes, il vous faudra utiliser journalctl --user -u tilix -f pour consulter les messages de votre service dans le journal et systemctl --user status tilix.service pour connaître l’état de votre service. À retenir aussi la commande systemctl --user reenable tilix.service qui va supprimer les symlinks créés par systemd pour démarrer le service et les recréer (This is a combination of disable and enable and is useful to reset the symlinks a unit file is enabled with to the defaults configured in its « [Install] » section), utile quand on se trompe dans la section [Install] (multi-user.target => default.target par exemple comme nous allons le voir après).

On part du principe que le service ne correspond pas exactement à ce que l’on souhaite (ça arrive souvent), on rentre donc dans une seconde phase, la modification du service et les commandes pour la prendre en compte. On modifie notre service car un truc nous convient pas nano ~/.config/systemd/user/tilix.service. On informe systemd que le service a été modifié et on redémarre le service systemctl --user daemon-reload; systemctl --user restart tilix. À connaître également on active le service à l’ouverture de la session et on le démarre systemctl --user --now enable tilix qui est l’équivalent de deux commandes --user enable et --user start.

tilix.service

La première version de mon service fut celle-ci, cat ~/.config/systemd/user/tilix.service.

[Unit]
Description=Tilix

[Service]
Type=simple
ExecStart=/usr/bin/tilix --minimize
Restart=always

[Install]
WantedBy=multi-user.target

Du très classique sur lequel je vais peu revenir, voir la documentation. Le Restart=always qui relance automatiquement Tilix dès qu’il est fermé, la commande à lancer ExecStart=/usr/bin/tilix --minimize. Dans mon cas je ne veux pas que Tilix ait le focus (soit au premier plan), je le veux minimisé.

La seconde version définitive.

[Unit]
Description=Tilix

[Service]
Type=simple
ExecStart=/usr/bin/tilix --minimize
KillMode=none
Restart=always

[Install]
WantedBy=default.target

J’ai remarqué rapidement que lorsque je fermais Tilix, toutes les applications que j’avais lancé via le terminal (par exemple Firefox ou TeamViewer) étaient fermées immédiatement. Voir KillMode. Autre subtilité/difficulté d’un service utilisateur, les targets ne sont pas les mêmes qu’un service systemd classique. Dans ce dernier vous verrez souvent WantedBy=multi-user.target alors que dans un service utilisateur, il n’y a pas multi-user.target notamment. Comparez systemctl list-units --type target et systemctl --user list-units --type target.

Euh… mais ça marche pas ?

Soudain le drame, Tilix n’est pas lancé à l’ouverture de la session après un redémarrage du pc. J’ai creusé, retourné, testé pensant que mon service Tilix n’était pas bon. L’un des côtés négatifs de mon syndrome de l’imposteur est que je vais passer X heures à chercher mon erreur sans envisager que ça ne vient pas de moi.

Après plusieurs heures de tests et de recherches vaines, j’allais raccrocher, la défaite était lourde. Je me suis souvenu qu’au boulot j’avais ramé deux heures sur un truc qui ne fonctionnait pas, c’était « juste » le script fourni qui était merdique. J’ai fait une recherche et en deux minutes j’ai trouvé le bug… Assez ironiquement il est reporté chez Red Hat depuis 15 jours, chez Ubuntu ça date. Il s’agit d’un bug lié à ECryptFS (partition /home chiffrée), j’ai testé la solution proposée avec /etc/pam.d/common-session mais ça ne fonctionne pas chez moi. J’ai confirmé le bug avec la session de Madame (partition /home non chiffrée), le service Tilix se lance bien à l’ouverture de session.

And voilà. Finalement j’ai ajouté dans l’utilitaire Session et démarrage de XFCE, Démarrage automatique d’application : systemctl --user --now enable tilix en attendant que le bug soit résolu.

Sources :
https://wiki.archlinux.fr/Systemd/utilisateur
https://vic.demuzere.be/articles/using-systemd-user-units/
https://unix.stackexchange.com/questions/385964/launching-chromium-on-startup-with-systemd