Wayland ne semble plus vouloir démarrer du premier coup

Support Debian
#1

Bonjour,

Je viens de galérer pour le titre du sujet, ce sera plus clair (je l’espère) après que j’explique le problème.

J’ai une machine sous Debian 12 sur laquelle j’ai mis l’environnement de bureau Plasma de KDE.
Lors du premier démarrage, le choix par défaut a été d’avoir une session Wayland.
J’ai réussi à régler les quelques petits soucis que j’ai eu pour le faire fonctionner correctement, à savoir la configuration de la sortie audio et un problème de correspondance de critère pour les règles de fenêtre.

Depuis hier, je n’arrive plus à lancer de session Wayland du premier coup. Lors du premier essai, les écrans affichent un fond noir avec la souris centrée sur l’écran de gauche, puis les écrans s’éteignent et se rallument plusieurs fois avant de revenir à l’écran de connexion.
J’ai remarqué que ça fonctionnait dès que XWayland utilisait :1 (ce qu’il faut au deuxième essai, je pense, car c’est :0 au premier essai). Mon hypothèse est qu’un blocage doit affecter :0, genre un fichier qui n’est pas accessible en écriture ou un reste de fichier temporaire d’une session précédente.
Les journaux sur les tentatives sont très verbeux (genre, plusieurs centaines de lignes pendant les tentatives de lancement), ils ne me permettent donc pas de trouver quelque chose.

Je ne sais pas si ça a un rapport, mais j’ai lancé une mise à jour hier, elle ne concernait que Chromium et Firefox, mais sait-on jamais.

Quelqu’un a une idée de ce que je peux faire ?

#2

Ah, j’ai peut-être ouvert le sujet un peu vite, mais j’ai trouvé ce qui ne fonctionnait pas, et c’est totalement de ma faute.
Contrairement à la session X11, la session Wayland a besoin de créer des fichiers dans le répertoire ~/.cache avant l’ouverture de la session. Or, il se trouve que, dans ma configuration, ~/.cache n’existe pas au démarrage car il est dans un répertoire temporaire.
J’ai donc résolu le problème en faisant en sorte qu’il soit créé avant l’ouverture de session à l’aide d’un service systemD :

[Unit]
Description=Dossiers temporaires pour almtesh
After=network.target

[Service]
User=almtesh
ExecStart=/usr/bin/mkdir -m 0700 /tmp/almtesh-cache/ /tmp/almtesh-misc /tmp/almtesh-downloads
Restart=no

[Install]
WantedBy=multi-user.target

J’ai trouvé la solution en pensant que c’était SDDM qui utilisait :0, j’ai donc cherché dans le manuel de la configuration de SDDM pour trouver comment le faire agir autrement. J’ai donc vu ça :

       SessionLogFile=
              Path to the user session log file, relative to the home directory. 
              Default value is ".local/share/sddm/wayland-session.log".

J’ai donc consulté ce fichier de journal et l’erreur était on-ne-peut-plus explicite et faisait état de l’impossibilité de créer des trucs dans ~/.cache.