Ubuntu 24.04 : « Failed to get D-Bus connection » — réparer les sessions et services cassés (cas n°48)

octobre 31, 2025 • février 3, 2026 • Lecture : 27 min • Views: 6

Cet article vous a aidé ?

Vous lancez systemctl et il répond : « Failed to get D-Bus connection ». Soudain votre « simple redémarrage » ressemble à une scène de crime : les services ne communiquent plus, les connexions semblent hantées, et toutes les automatisations qui attendent une session propre commencent à échouer.

Cette erreur n’est que rarement « juste D-Bus ». Il s’agit généralement d’un contrat brisé entre systemd, votre login/session et les sockets de bus sous /run. La réparation est ennuyeuse — mais seulement après que vous ayez arrêté de deviner et commencé à prouver.

Ce que l’erreur signifie réellement (et ce qu’elle ne signifie pas)

Quand un outil indique « Failed to get D-Bus connection », il se plaint de ne pas pouvoir atteindre un socket de bus de messages qu’il s’attend à trouver. Sur Ubuntu 24.04, l’appelant habituel est systemctl, loginctl, des composants GNOME, des invites policykit, des aides snapd, ou tout processus qui attend soit :

Le bus système à /run/dbus/system_bus_socket (utilisé pour les services système), ou
Le bus de session utilisateur (par utilisateur) typiquement à /run/user/UID/bus, géré par systemd --user et dbus-daemon ou dbus-broker selon la configuration.

La formulation est trompeuse parce que la cause racine n’est souvent pas « D-Bus en panne ». Le bus peut très bien fonctionner ; votre environnement peut être incorrect, votre répertoire runtime peut ne pas exister, vous pouvez être dans un conteneur/namespace, ou vous pouvez utiliser sudo d’une manière qui supprime les variables du bus.

Deux règles pour rester sain d’esprit :

Décidez si vous avez besoin du bus système ou du bus utilisateur. Si vous gérez des services avec systemctl (scope système), vous vous préoccupez du PID 1, de dbus et du socket système. Si vous lancez des actions de bureau/session, vous vous préoccupez de systemd --user, de XDG_RUNTIME_DIR et du socket par utilisateur.
Testez toujours le socket, pas vos impressions. La plupart des pannes « connexion D-Bus » sont en réalité des chemins /run manquants, des sessions utilisateur mortes, ou un gestionnaire de connexion cassé.

Une idée paraphrasée de Gene Kim (auteur DevOps/fiabilité) : Les améliorations viennent en réduisant le travail en cours et en rendant les problèmes visibles tôt. Cela s’applique ici : rendez l’échec visible en vérifiant d’abord les chemins de bus et l’état des sessions, au lieu de redémarrer des démons au hasard.

Mode d’urgence : diagnostic rapide

Quand cela se produit en production à 02:00, vous ne voulez pas de théorie. Vous voulez une boucle de triage qui converge.

Étape 1 : Identifiez quel bus échoue

Si l’erreur apparaît en lançant systemctl status foo en root, il s’agit probablement du bus système ou de la connectivité vers PID 1.
Si l’erreur apparaît dans une application de bureau, les paramètres GNOME ou systemctl --user, c’est le bus de session utilisateur (/run/user/UID/bus).
Si cela n’arrive que via SSH ou dans de l’automatisation, suspectez les variables d’environnement et les shells non-login.

Étape 2 : Vérifiez les sockets et répertoires runtime (signal le plus rapide)

/run/dbus/system_bus_socket existe et est un socket ?
/run/user/UID existe et est possédé par l’utilisateur ?
/run/user/UID/bus existe et est un socket ?

Étape 3 : Validez le gestionnaire de session et l’état de systemd

systemctl is-system-running vous dit si PID 1 est sain.
systemctl status dbus vous indique si le service dbus existe/démarré.
loginctl list-sessions vous dit si logind voit votre session (critique pour la création de /run/user/UID).

Étape 4 : Réparez la bonne couche, pas la plus bruyante

Manque /run/user/UID ? Réparez le cycle de vie logind/session.
Le socket existe mais accès refusé ? Corrigez les permissions, les politiques SELinux/AppArmor ou le contexte utilisateur.
Fonctionne en local mais pas avec sudo ? Corrigez la préservation d’environnement, ne « redémarrez pas dbus » par dépit.

Faits et contexte intéressants (vous déboguerez plus vite)

D-Bus a été conçu au début des années 2000 pour remplacer des mécanismes IPC ad hoc sur les bureaux Linux ; il est devenu, par la suite, un pilier pour les services système aussi.
systemd n’a pas créé D-Bus, mais systemd a rendu les dépendances D-Bus plus explicites avec l’ordre des unités, l’activation par socket et les services utilisateur.
Les répertoires runtime utilisateur sous /run/user/UID sont généralement créés par systemd-logind lors du démarrage d’une session — et supprimés à la fin de la dernière session.
Ubuntu a livré à la fois dbus-daemon et des alternatives (comme dbus-broker dans certains environnements) ; ce qui compte est le contrat du socket, pas la marque de l’implémentation.
XDG_RUNTIME_DIR fait partie de la spec XDG Base Directory ; il doit être spécifique à l’utilisateur, sécurisé et éphémère — exactement le contraire d’un répertoire aléatoire sous /tmp.
systemctl communique avec systemd via D-Bus ; si systemctl ne peut pas atteindre un bus, il ne peut rien demander à systemd, même si systemd est techniquement vivant.
Les sessions SSH ne sont pas toujours « sessions logind » selon la configuration PAM ; lorsqu’elles ne le sont pas, vous pouvez perdre la création automatique du répertoire runtime et l’accès au bus utilisateur.
Les conteneurs n’ont souvent pas de bus système complet parce que PID 1 n’est pas systemd, ou parce que /run est isolé. Cette erreur y est normale sauf si vous la raccordez volontairement.
PolicyKit (polkit) dépend de D-Bus pour les requêtes d’autorisation ; un accès bus cassé peut se traduire par « les invites d’authentification n’apparaissent jamais » ou « permission denied » sans UI.

Blague #1 : D-Bus, c’est comme le courrier interne du bureau — quand il tombe en panne, tout le monde découvre soudain combien de choses en dépendent sans qu’on le sache.

Guide de terrain : isoler quel « bus » est inaccessible

Il existe quelques formes d’échec courantes :

Root sur un serveur : systemctl échoue. Habituellement le socket du bus système est manquant, l’unité dbus est failed, ou PID 1 est dans un état dégradé/à moitié mort.
Session utilisateur de bureau : les paramètres GNOME échouent, gsettings casse, systemctl --user échoue. Habituellement XDG_RUNTIME_DIR n’est pas défini, /run/user/UID est manquant, ou systemd --user ne fonctionne pas.
Automatisation via sudo : fonctionne en tant qu’utilisateur, échoue en root, ou l’inverse. Habituellement les variables d’environnement et le contexte de session sont incorrects.
Dans des conteneurs/CI : systemctl et busctl échouent par conception parce qu’il n’y a pas de systemd PID 1.

Voici l’idée clé : le bus est un fichier socket Unix. Si le socket n’est pas là, vous n’allez pas « réessayer plus fort ». S’il est là mais que votre processus ne peut pas y accéder, vous avez des problèmes de permissions, de namespaces ou d’identité. S’il est là et accessible mais que les réponses échouent, alors vous avez un problème de démon.

Tâches pratiques : commandes, sorties attendues et décisions

Voici les tâches que j’exécute réellement. Chacune inclut ce que la sortie signifie et quelle décision prendre ensuite. Lancez-les dans l’ordre jusqu’à ce que le mode de défaillance devienne évident. Vous ne collectez pas des logs pour le plaisir ; vous réduisez l’espace de recherche.

Task 1: Confirm the exact failing command and context

cr0x@server:~$ whoami
cr0x
cr0x@server:~$ systemctl status ssh
Failed to get D-Bus connection: No such file or directory

Signification : Le client ne peut pas atteindre son socket de bus. « No such file or directory » suggère un chemin de socket manquant, pas un problème de permission.

Décision : Déterminez s’il s’agit d’un échec du bus système (scope système) ou du bus utilisateur (scope utilisateur). Ensuite : vérifiez si vous êtes root et quel systemctl vous avez lancé.

Task 2: Check whether PID 1 is systemd (containers and chroots)

cr0x@server:~$ ps -p 1 -o pid,comm,args
  PID COMMAND         COMMAND
    1 systemd         /sbin/init

Signification : PID 1 est systemd ; systemctl devrait fonctionner si le chemin du bus système est présent.

Décision : Si PID 1 n’est pas systemd (commun dans les conteneurs), la « correction » consiste à éviter systemctl ou à exécuter un init adéquat. Si c’est systemd, continuez.

Task 3: Verify the system bus socket exists

cr0x@server:~$ ls -l /run/dbus/system_bus_socket
srwxrwxrwx 1 root root 0 Dec 30 10:12 /run/dbus/system_bus_socket

Signification : Le fichier socket du bus système existe et est bien un socket (le préfixe s dans les permissions). Le fait qu’il soit accessible en écriture pour tous est normal pour l’endpoint ; le contrôle d’accès reste géré par la politique D-Bus.

Décision : Si manquant : concentrez-vous sur le service dbus et les problèmes d’amorçage précoces. S’il est présent : testez si dbus répond.

Task 4: Check dbus service health (system bus)

cr0x@server:~$ systemctl status dbus --no-pager
● dbus.service - D-Bus System Message Bus
     Loaded: loaded (/usr/lib/systemd/system/dbus.service; static)
     Active: active (running) since Mon 2025-12-30 10:12:01 UTC; 2min ago
TriggeredBy: ● dbus.socket
       Docs: man:dbus-daemon(1)
   Main PID: 842 (dbus-daemon)
      Tasks: 1 (limit: 18939)
     Memory: 3.8M
        CPU: 52ms

Signification : Le bus système est en cours d’exécution ; le problème peut être la capacité de systemctl à se connecter à systemd (pas dbus), ou un problème de namespace/permission.

Décision : Si dbus est inactive/failed, redémarrez-le et lisez les logs. S’il est actif, vérifiez systemd lui-même et le socket privé de systemd.

Task 5: Confirm systemd is responsive

cr0x@server:~$ systemctl is-system-running
running

Signification : PID 1 rapporte un état sain. Si vous voyez encore « Failed to get D-Bus connection », vous exécutez peut-être systemctl dans un environnement qui ne voit pas /run ou qui manque le namespace de montage correct.

Décision : Si la sortie est degraded ou maintenance, allez directement dans le journal pour les pannes systémiques. Si c’est running mais que les clients échouent, suspectez un namespace, un chroot ou des problèmes de système de fichiers sous /run.

Task 6: Inspect /run mount and free space (yes, really)

cr0x@server:~$ findmnt /run
TARGET SOURCE FSTYPE OPTIONS
/run   tmpfs  tmpfs  rw,nosuid,nodev,relatime,size=394680k,mode=755,inode64
cr0x@server:~$ df -h /run
Filesystem      Size  Used Avail Use% Mounted on
tmpfs           386M  2.1M  384M   1% /run

Signification : /run est un tmpfs ; il doit être inscriptible et disposer d’espace/inodes. Si /run est en lecture seule ou plein, les sockets ne pourront pas être créés et vous obtiendrez des erreurs de bus manquant.

Décision : Si plein/ro : corrigez cela d’abord (souvent un processus hors contrôle ou une mauvaise taille de tmpfs). Si sain : continuez aux vérifications de session utilisateur si l’erreur est en scope utilisateur.

Task 7: Determine if you’re dealing with the user bus

cr0x@server:~$ echo "$XDG_RUNTIME_DIR"
/run/user/1000
cr0x@server:~$ echo "$DBUS_SESSION_BUS_ADDRESS"
unix:path=/run/user/1000/bus

Signification : Les variables d’environnement pointent vers le bus par utilisateur. Si l’une est vide, votre session est incomplète (courant avec sudo, cron ou PAM cassé).

Décision : Si non définies : vous devez établir un contexte de session approprié ou configurer explicitement un bus utilisateur (privilégiez la première option). Si définies : vérifiez que le socket existe.

Task 8: Validate the user bus socket exists and has sane ownership

cr0x@server:~$ id -u
1000
cr0x@server:~$ ls -ld /run/user/1000
drwx------ 12 cr0x cr0x 320 Dec 30 10:12 /run/user/1000
cr0x@server:~$ ls -l /run/user/1000/bus
srw-rw-rw- 1 cr0x cr0x 0 Dec 30 10:12 /run/user/1000/bus

Signification : Le répertoire runtime existe, est privé (0700) et le socket du bus existe. Bien. Si /run/user/1000 est manquant, votre session n’a pas été enregistrée correctement auprès de logind.

Décision : Si manquant : passez à la résolution via loginctl et PAM/logind. S’il est présent mais mal possédé : corrigez la propriété et enquêtez pourquoi elle a dérivé (souvent un script malveillant exécuté en root).

Task 9: Prove the user systemd instance is alive

cr0x@server:~$ systemctl --user status --no-pager
● cr0x@server
    State: running
    Units: 221 loaded (incl. snap units)
     Jobs: 0 queued
   Failed: 0 units
    Since: Mon 2025-12-30 10:12:05 UTC; 2min ago

Signification : Votre gestionnaire utilisateur fonctionne et est joignable. Si vous obtenez « Failed to connect to bus », le chemin du bus utilisateur ou l’environnement est cassé.

Décision : Si cela échoue mais que le socket existe, votre environnement peut mentir (mauvais XDG_RUNTIME_DIR) ou vous êtes dans un namespace différent (commun avec sudo et certains outils distants).

Task 10: Use loginctl to verify logind sees your session

cr0x@server:~$ loginctl list-sessions
SESSION  UID USER SEAT  TTY
     21 1000 cr0x seat0 tty2

1 sessions listed.
cr0x@server:~$ loginctl show-user cr0x -p RuntimePath -p State -p Linger
RuntimePath=/run/user/1000
State=active
Linger=no

Signification : logind a une session active pour l’utilisateur et connaît le chemin runtime. S’il n’y a pas de sessions, votre répertoire runtime utilisateur peut ne pas être créé.

Décision : Si la session est absente via SSH : vérifiez la configuration PAM et si votre chemin de connexion utilise systemd/logind. Si vous avez besoin de services utilisateur en arrière-plan, envisagez le lingering (prudemment).

Task 11: Diagnose “sudo broke my bus” (classic)

cr0x@server:~$ sudo -i
root@server:~# echo "$DBUS_SESSION_BUS_ADDRESS"

root@server:~# systemctl --user status
Failed to connect to bus: No medium found

Signification : Le shell root n’a pas de contexte de bus utilisateur ; systemctl --user sous root n’est pas votre session utilisateur. Cette erreur est attendue.

Décision : Ne « corrigez » pas cela en exportant des variables aléatoires dans root. Utilisez systemctl (scope système) en root, et systemctl --user en tant qu’utilisateur dans la session. Si vous devez gérer une unité utilisateur depuis root, utilisez machinectl shell ou runuser avec l’environnement approprié, ou ciblez le gestionnaire utilisateur via loginctl enable-linger et exécutez systemctl --user sous cet utilisateur.

Task 12: Check journal for the first failure, not the last complaint

cr0x@server:~$ journalctl -b -u systemd-logind --no-pager | tail -n 20
Dec 30 10:11:58 server systemd-logind[701]: New session 21 of user cr0x.
Dec 30 10:11:58 server systemd-logind[701]: Watching system buttons on /dev/input/event3 (Power Button)
Dec 30 10:12:01 server systemd-logind[701]: Removed session 19.

Signification : logind crée des sessions. Si vous voyez à la place des échecs répétés pour créer des répertoires runtime, c’est votre indice principal.

Décision : Si logind affiche des erreurs concernant le répertoire runtime ou les cgroups, corrigez ces couches. Redémarrer dbus ne réparera pas « impossibilité de créer /run/user/UID ».

Task 13: Confirm dbus packages and user-session support are installed

cr0x@server:~$ dpkg -l | egrep 'dbus|dbus-user-session|libpam-systemd' | awk '{print $1,$2,$3}'
ii dbus 1.14.10-4ubuntu4.1
ii dbus-user-session 1.14.10-4ubuntu4.1
ii libpam-systemd 255.4-1ubuntu8

Signification : Les composants requis existent. L’absence de dbus-user-session peut entraîner un comportement de bus de session manquant sur certaines installations minimales.

Décision : Si manquant : installez les paquets manquants et reconnectez-vous. S’ils sont présents : poursuivez vers PAM/logind et les problèmes d’environnement.

Task 14: Check PAM session hooks for systemd/logind (SSH-focused)

cr0x@server:~$ grep -R "pam_systemd.so" -n /etc/pam.d/sshd /etc/pam.d/login
/etc/pam.d/sshd:15:session    required     pam_systemd.so
/etc/pam.d/login:14:session    required     pam_systemd.so

Signification : PAM est configuré pour enregistrer les sessions auprès de systemd/logind pour SSH et les connexions console. Si absent, vous pouvez vous retrouver sans répertoire runtime et sans bus utilisateur.

Décision : Si absent pour le chemin de connexion utilisé : ajoutez-le (prudemment, avec contrôle de changement) et testez avec une nouvelle session. Si présent : concentrez-vous sur pourquoi logind ne crée toujours pas les répertoires runtime (souvent lié au lingering, aux cgroups ou à un état systemd cassé).

Task 15: Check if the user runtime dir is being removed unexpectedly

cr0x@server:~$ sudo ls -l /run/user
total 0
drwx------ 12 cr0x cr0x 320 Dec 30 10:12 1000
drwx------ 10 gdm  gdm  280 Dec 30 10:11 120

Signification : Les répertoires runtime existent pour les utilisateurs actifs. Si le vôtre disparaît à la déconnexion SSH, vous n’avez probablement pas de lingering et vous n’avez pas de session active.

Décision : Pour des services utilisateur en arrière-plan : envisagez loginctl enable-linger username. Pour le travail interactif : assurez-vous d’avoir une vraie session et évitez d’exécuter des commandes dépendantes de la session depuis des contextes non-session.

Task 16: Enable lingering (only if you truly need user services without a login)

cr0x@server:~$ sudo loginctl enable-linger cr0x
cr0x@server:~$ loginctl show-user cr0x -p Linger
Linger=yes

Signification : Le gestionnaire utilisateur peut survivre au-delà des connexions, maintenant les services utilisateur et le répertoire runtime disponibles.

Décision : Utilisez cela pour des services headless exécutés en scope utilisateur (parfois agents CI, podman par utilisateur, etc.). Ne l’activez pas partout « au cas où ». C’est comme ça qu’on obtient des gestionnaires utilisateur zombies consommant de la RAM sur des hôtes partagés.

Task 17: If systemctl fails as root, test D-Bus directly

cr0x@server:~$ busctl --system list | head
NAME                      PID PROCESS         USER CONNECTION UNIT SESSION DESCRIPTION
:1.0                      842 dbus-daemon     root :1.0       -    -       -
org.freedesktop.DBus      842 dbus-daemon     root :1.0       -    -       -
org.freedesktop.login1    701 systemd-logind  root :1.2       -    -       -

Signification : Le bus système répond. Si systemctl renvoie encore une erreur, vous pourriez avoir un endpoint D-Bus systemd cassé ou un décalage d’environnement/namespace.

Décision : Si busctl échoue aussi : le bus système est vraiment cassé. Si busctl fonctionne : concentrez-vous sur la connectivité systemd et l’environnement client.

Task 18: Check the systemd private socket (systemd’s IPC endpoint)

cr0x@server:~$ ls -l /run/systemd/private
srw------- 1 root root 0 Dec 30 10:11 /run/systemd/private

Signification : Le socket privé de systemd existe ; systemctl l’utilise sur certains chemins. S’il manque, quelque chose est profondément incorrect avec PID 1 ou /run.

Décision : S’il manque : traitez-le comme un problème systemd/système de fichiers runtime ; envisagez un redémarrage contrôlé après avoir extrait les logs. S’il est présent : revenez à la portée (système vs utilisateur) et aux problèmes de namespace.

Task 19: Spot chroot/namespace issues (common in recovery shells)

cr0x@server:~$ readlink /proc/$$/ns/mnt
mnt:[4026532585]
cr0x@server:~$ sudo readlink /proc/1/ns/mnt
mnt:[4026531840]

Signification : Votre shell est dans un namespace de montage différent de PID 1. Vous pourriez ne pas voir le vrai /run où résident les sockets.

Décision : Si les namespaces diffèrent, exécutez les diagnostics depuis le namespace hôte (ou entrez-y) au lieu de « réparer » des chemins fantômes dans votre vue isolée.

Task 20: Last resort, controlled restarts (in the right order)

cr0x@server:~$ sudo systemctl restart systemd-logind
cr0x@server:~$ sudo systemctl restart dbus
cr0x@server:~$ sudo systemctl daemon-reexec

Signification : Ces redémarrages peuvent récupérer un logind/dbus/systemd bloqué. daemon-reexec est lourd ; il ré-exécute PID 1 sans rebooter.

Décision : N’exécutez cela qu’après avoir confirmé que vous n’êtes pas dans un conteneur et après avoir capturé suffisamment de logs pour expliquer l’incident. Si les sessions utilisateur sont cassées à cause de logind, redémarrer logind peut couper des sessions ; planifiez-le en connaissance de cause.

Erreurs courantes : symptôme → cause → correction

1) « systemctl fonctionne en local en root, échoue via SSH »

Symptôme : Via SSH, systemctl renvoie « Failed to get D-Bus connection », mais sur la console ça marche.

Cause racine : Vous êtes dans un environnement restreint (commande forcée, chroot, toolbox), ou votre session SSH ne voit pas le /run de l’hôte (différence de namespace de montage).

Correction : Confirmez PID 1 et le namespace de montage ; assurez-vous que votre chemin SSH n’est pas chrooté et a accès à /run. Utilisez la Task 2 et la Task 19.

2) « systemctl –user échoue après sudo -i »

Symptôme : Vous devenez root et tentez de gérer des services utilisateur ; ça échoue avec des erreurs de bus.

Cause racine : Root n’a pas le contexte du bus utilisateur. De plus, le gestionnaire utilisateur de root n’est pas votre gestionnaire utilisateur.

Correction : Exécutez systemctl --user en tant qu’utilisateur dans la session. Si nécessaire depuis root, utilisez runuser -l username -c 'systemctl --user …' et assurez-vous qu’une session appropriée existe (ou activez le lingering).

3) « GNOME Settings ne s’ouvre pas ; les invites polkit n’apparaissent jamais »

Symptôme : Les actions GUI échouent silencieusement ou se plaignent de D-Bus.

Cause racine : Le bus de session utilisateur est cassé : XDG_RUNTIME_DIR manquant, DBUS_SESSION_BUS_ADDRESS obsolète, ou /run/user/UID/bus manquant.

Correction : Vérifiez Task 7/8. Déconnectez-vous et reconnectez-vous pour recréer une session propre. Si ça persiste, vérifiez logind et l’intégration PAM.

4) « Script cron échoue avec erreurs de connexion D-Bus »

Symptôme : Un script utilisant gsettings, notify-send ou systemctl --user échoue dans cron.

Cause racine : Cron s’exécute sans session utilisateur et sans XDG_RUNTIME_DIR.

Correction : N’exécutez pas de commandes dépendant du bureau/session dans cron à moins de créer un contexte de session. Utilisez des services système à la place, ou activez le lingering et exécutez un service utilisateur indépendant de l’état GUI.

5) « /run/user/UID existe mais appartient à root »

Symptôme : Le répertoire existe, mais les permissions sont erronées ; des erreurs de bus utilisateur suivent.

Cause racine : Quelqu’un a lancé un « nettoyage » en root et recréé les répertoires incorrectement, ou un script défaillant a écrit dans /run/user.

Correction : Déconnectez l’utilisateur (terminez les sessions), supprimez le répertoire runtime incorrect et laissez logind le recréer. Si vous devez corriger en direct, corrigez la propriété et redémarrez prudemment le gestionnaire utilisateur.

6) « socket du bus système manquant après le boot »

Symptôme : /run/dbus/system_bus_socket est absent ; systemctl échoue globalement.

Cause racine : dbus.socket ou dbus.service n’a pas démarré, ou /run n’a pas été monté correctement.

Correction : Validez le montage /run (Task 6), puis systemctl status dbus dbus.socket, et vérifiez les logs du boot précoce.

7) « Ça marche sur l’hôte mais échoue dans un conteneur »

Symptôme : systemctl et busctl échouent dans une image conteneur ou un runner CI.

Cause racine : Pas de systemd PID 1, pas de bus système, ou /run isolé.

Correction : N’utilisez pas systemctl dans ce conteneur. Lancez le service en avant-plan, ou exécutez un conteneur basé sur systemd intentionnellement avec les privilèges et mounts appropriés.

Trois mini-récits d’entreprise venant du terrain

Mini-récit n°1 : L’incident causé par une mauvaise hypothèse

Dans une entreprise de taille moyenne, un ingénieur on-call a reçu une alerte « l’hôte de déploiement ne redémarre pas les services ». Il s’est connecté en SSH, a lancé sudo systemctl restart app, et a reçu « Failed to get D-Bus connection ». L’hypothèse fut immédiate et confiante : « dbus est en panne ; redémarrons-le. »

Il a redémarré dbus. Puis logind. Puis tenté un daemon-reexec. L’hôte est devenu plus difficile d’accès, et quelques sessions interactives ont été coupées. L’application ne redémarrait toujours pas. L’incident a pris de l’ampleur.

Le vrai problème était banal : l’ingénieur n’était pas sur l’hôte. Il se trouvait dans un chroot de maintenance utilisé par les outils de secours de l’équipe. Cet environnement avait un namespace de montage différent et un /run différent. Évidemment /run/dbus/system_bus_socket n’existait pas là ; le socket du bus vivait dans le namespace de l’hôte.

Une fois sorti du chroot et la même commande lancée dans l’environnement réel de l’hôte, systemctl a fonctionné immédiatement. La « panne D-Bus » était une mirage créée par le contexte. La correction fut d’ajouter une bannière claire pour les environnements de secours et d’apprendre à l’équipe à exécuter la Task 2 et la Task 19 avant de toucher aux démons.

Mini-récit n°2 : L’optimisation qui s’est retournée

Une autre équipe voulait des temps de connexion plus rapides et moins de processus en arrière-plan sur des postes développeurs. Quelqu’un a décidé de « simplifier » en retirant des paquets de l’image de base, y compris des composants de session qu’ils considéraient comme du « fluff » desktop.

L’image a été déployée, et elle était rapide. Pendant environ une semaine. Puis sont arrivés les tickets : intégration IDE en panne, invites de mot de passe qui n’apparaissent pas, basculements de paramètres inefficaces, et une étrange — services utilisateur ne fonctionnant que après reconnexion via bureau à distance.

Ils avaient retiré des éléments qui assuraient indirectement un bus de session utilisateur stable. Le bus système existait toujours, mais l’infrastructure par utilisateur était incohérente selon les méthodes de connexion. Certaines connexions créaient correctement /run/user/UID ; d’autres non, parce que les hooks PAM étaient incomplets et les paquets de session utilisateur absents.

L’optimisation n’était pas « mauvaise » parce qu’elle économisait du CPU. Elle était mauvaise parce qu’elle supprimait l’échafaudage rendant le bus utilisateur prévisible. Le rollback a réinstallé les paquets nécessaires et standardisé les chemins de connexion. Le temps de connexion a légèrement augmenté, et le taux d’incidents a fortement diminué. Parfois « rapide » n’est que « fragile avec un meilleur marketing ».

Mini-récit n°3 : La pratique ennuyeuse mais correcte qui a sauvé la journée

Dans un environnement régulé, une équipe gérait des serveurs Ubuntu qui avaient parfois besoin d’un travail d’urgence sur console. Ils avaient une politique qui semblait old-school : chaque intervention commence par capturer l’état, y compris des extraits de journalctl -b et un instantané des chemins de sockets dans /run, avant tout redémarrage.

Cela semblait bureaucratique jusqu’à ce qu’un hôte production commence à lancer des erreurs de connexion D-Bus après une mise à jour du noyau. L’on-call a suivi la politique. Il a capturé findmnt /run, vérifié l’espace libre, confirmé que /run/systemd/private existait, et noté que /run/dbus/system_bus_socket était manquant. Il a aussi récupéré les logs de boot montrant des avertissements de montage tmpfs précoces.

Parce qu’ils avaient des preuves, ils n’ont pas thrashé. Ils ont trouvé que /run était monté en lecture seule à cause d’une défaillance subtile d’initramfs/mount. Avec la correction et un redémarrage contrôlé, le socket du bus est apparu, systemctl a récupéré et la panne s’est terminée proprement.

La pratique ennuyeuse n’a pas seulement réparé la machine ; elle a préservé le récit. En environnements corporate, le récit est la moitié de la récupération : il faut expliquer ce qui s’est passé sans accuser des rayons cosmiques.

Listes de vérification / plan étape par étape

Checklist A: Vous voyez « Failed to get D-Bus connection » en lançant systemctl (scope système)

Confirmez que vous êtes sur l’hôte et que PID 1 est systemd (Task 2).
Vérifiez le montage et la capacité de /run (Task 6).
Vérifiez que /run/dbus/system_bus_socket existe (Task 3).
Contrôlez systemctl status dbus dbus.socket (Task 4).
Vérifiez le socket privé de systemd /run/systemd/private (Task 18).
Testez la réactivité du bus avec busctl --system list (Task 17).
Récupérez les logs : journalctl -b et les unités concernées (Task 12).
Si vous devez redémarrer, faites-le délibérément : logind → dbus → daemon-reexec (Task 20).

Checklist B: Vous voyez l’erreur en lançant systemctl –user ou des outils de bureau (scope utilisateur)

Vérifiez XDG_RUNTIME_DIR et DBUS_SESSION_BUS_ADDRESS (Task 7).
Vérifiez que /run/user/UID et /run/user/UID/bus existent et appartiennent à l’utilisateur (Task 8).
Contrôlez systemctl --user status (Task 9).
Utilisez loginctl list-sessions et loginctl show-user (Task 10).
Si c’est SSH/cron, décidez : avez-vous besoin d’une vraie session ou d’un service système à la place ?
Si vous avez besoin de services utilisateur en arrière-plan, activez le lingering pour cet utilisateur (Task 16), puis retestez.
Si le répertoire runtime disparaît continuellement, corrigez le cycle de vie des sessions et PAM (Task 14/15).

Checklist C: Vous êtes en automatisation/CI et ça échoue

Confirmez si vous êtes dans un conteneur et que PID 1 n’est pas systemd (Task 2).
Cessez d’essayer d’utiliser systemctl dans cet environnement. Lancez le service directement, ou re-concevez le job.
Si vous avez vraiment besoin de systemd, exécutez un environnement compatible systemd intentionnellement, pas par accident.

Blague #2 : Redémarrer dbus sans vérifier les sockets, c’est comme redémarrer une imprimante parce qu’il n’y a plus de papier — cathartique, inefficace, et étrangement populaire.

FAQ

1) Pourquoi `systemctl` utilise-t-il D-Bus du tout ?

systemctl est un client. Il parle aux APIs du gestionnaire systemd, exposées généralement via D-Bus et le socket privé de systemd. Pas de bus, pas de conversation.

2) Je vois `dbus-daemon` en fonctionnement. Pourquoi j’obtiens toujours l’erreur ?

Parce que le processus daemon existant n’est pas la même chose que l’accessibilité du socket dans votre namespace/contexte. Vérifiez les chemins de socket sous /run et confirmez que vous êtes dans le namespace de montage de l’hôte (Task 3, 6, 19).

3) Que changent « No such file or directory » vs « Permission denied » ?

No such file signifie généralement que le chemin du socket n’existe pas dans votre vue (montage /run manquant, répertoire runtime absent, problème de namespace). Permission denied signifie que le socket existe mais que le contrôle d’accès vous bloque (mauvais utilisateur, politique ou confinement).

4) Pourquoi ça casse seulement via SSH ?

Soit votre session SSH n’est pas enregistrée auprès de logind (mauvaise configuration PAM), soit vous exécutez dans un wrapper/chroot restreint. Vérifiez pam_systemd.so et si /run/user/UID est créé pour cette session (Task 10, 14).

5) Est-ce sûr d’activer le lingering ?

C’est sûr si vous savez pourquoi vous en avez besoin : exécuter des services utilisateur sans connexions actives. C’est dangereux comme palliatif généralisé car vous conserverez des gestionnaires utilisateur vivants, ce qui peut masquer des bugs de déconnexion et gaspiller des ressources. Activez-le utilisateur par utilisateur, délibérément (Task 16).

6) Puis-je simplement exporter `DBUS_SESSION_BUS_ADDRESS` et continuer ?

Vous pouvez, mais vous ne devriez pas. Exporter des adresses obsolètes crée des « ça marche sur ma console » fantômes qui casseront plus tard. Préférez établir une vraie session et laissez logind/systemd définir XDG_RUNTIME_DIR et l’adresse du bus.

7) Quelle est la façon la plus rapide de distinguer bus système vs bus utilisateur ?

Si vous utilisez systemctl sans --user, c’est le scope système. Si le socket pertinent est /run/dbus/system_bus_socket, c’est le bus système. Si c’est /run/user/UID/bus, c’est le bus de session utilisateur.

8) Je suis sur une installation serveur minimale — ai-je besoin de `dbus-user-session` ?

Si vous exécutez des services en scope utilisateur ou attendez qu’une session utilisateur ait un bus, oui, c’est souvent nécessaire. Si vous ne gérez que des services système, vous pouvez parfois vous en passer. Réponse guidée par le symptôme : si le bus utilisateur manque, vérifiez la présence des paquets (Task 13).

9) Pourquoi `systemctl --user` échoue en root alors que l’utilisateur est connecté ?

Parce que l’environnement de root n’est pas celui de l’utilisateur, et root n’est pas « attaché » au bus de session de cet utilisateur. Exécutez la commande en tant qu’utilisateur dans la session, ou utilisez un outil approprié pour cibler ce gestionnaire utilisateur.

10) Quand dois-je rebooter au lieu de déboguer ?

Si PID 1 est malsain, /run est corrompu/en lecture seule, ou les sockets systemd manquent et vous ne pouvez pas les récupérer proprement, un redémarrage contrôlé est souvent la solution la plus fiable. Capturez les logs avant.

Conclusion : prochaines étapes à déployer aujourd’hui

« Failed to get D-Bus connection » n’est pas une invitation à redémarrer des services au hasard. C’est une demande de vérification d’un contrat : /run est monté et inscriptible, le bon socket existe, votre session est réelle et votre environnement pointe vers le bus correct.

Faites ceci ensuite :

Exécutez le playbook rapide : sockets, répertoires runtime, sessions logind. Ne sautez pas aux redémarrages.
Décidez si votre workflow dépend du bus utilisateur. Si oui, standardisez les chemins de connexion (PAM + logind) et évitez cron pour le travail de session.
Si c’est un problème de parc, ajoutez une vérification de santé légère : validez que /run/dbus/system_bus_socket et /run/systemd/private existent, et alertez sur les répertoires runtime manquants pour les sessions actives.
Rédigez la règle de contexte : les chroots/conteneurs sont autorisés à échouer sur systemctl. Vos playbooks doivent l’indiquer clairement.