Ubuntu 24.04: “Failed to get D-Bus connection” — fix broken sessions and services (case #48)

October 31, 2025 • February 3, 2026 • Read: 22 min • Views: 10

Was this helpful?

You run systemctl and it spits: “Failed to get D-Bus connection”. Suddenly your “simple restart” turns into a crime scene: services won’t talk, logins look haunted, and every automation that expects a clean session starts failing.

This error is rarely “just D-Bus.” It’s usually a broken contract between systemd, your login/session, and the bus sockets under /run. The fix is boring—but only after you stop guessing and start proving.

What the error really means (and what it doesn’t)

When a tool says “Failed to get D-Bus connection”, it’s complaining that it can’t reach a message bus socket it expects to exist. On Ubuntu 24.04, the usual caller is systemctl, loginctl, GNOME components, policykit prompts, snapd helpers, or any process that expects either:

The system bus at /run/dbus/system_bus_socket (used for system-wide services), or
The user session bus (per-user) typically at /run/user/UID/bus, managed by systemd --user and dbus-daemon or dbus-broker depending on the setup.

The phrase is misleading because the root cause is often not “D-Bus is down.” The bus may be fine; your environment may be wrong, your runtime directory may not exist, you might be inside a container/namespace, or you might be using sudo in a way that strips the bus variables.

Two rules that keep you sane:

Decide if you need the system bus or the user bus. If you’re managing services with systemctl (system scope), you care about PID 1, dbus, and the system socket. If you’re running desktop/session actions, you care about systemd --user, XDG_RUNTIME_DIR, and the per-user socket.
Always test the socket, not your feelings. Most “D-Bus connection” outages are actually missing /run paths, dead user sessions, or a broken login manager.

One paraphrased idea from Gene Kim (DevOps/reliability author): Improvement comes from reducing work-in-progress and making problems visible early. That applies here: make the failure visible by checking the bus paths and session state first, not by restarting random daemons.

Fast diagnosis playbook

When this hits production at 02:00, you don’t want theory. You want a triage loop that converges.

Step 1: Identify which bus is failing

If the error appears while running systemctl status foo as root, it’s likely the system bus or PID 1 connectivity.
If the error appears in a desktop app, GNOME settings, or systemctl --user, it’s the user session bus (/run/user/UID/bus).
If it only happens over SSH or automation, suspect environment variables and non-login shells.

Step 2: Check sockets and runtime dirs (fastest signal)

/run/dbus/system_bus_socket exists and is a socket?
/run/user/UID exists and is owned by the user?
/run/user/UID/bus exists and is a socket?

Step 3: Validate the session manager and systemd state

systemctl is-system-running tells you if PID 1 is healthy.
systemctl status dbus tells you if the system bus service exists/started.
loginctl list-sessions tells you if logind sees your session (critical for /run/user/UID creation).

Step 4: Fix the right layer, not the loudest one

Missing /run/user/UID? Fix logind/session lifecycle.
Socket exists but access denied? Fix permissions, SELinux/AppArmor policies, or the user context.
Works locally but not with sudo? Fix environment preservation, don’t “restart dbus” out of spite.

Interesting facts and context (you’ll debug faster)

D-Bus was designed in the early 2000s to replace ad-hoc IPC mechanisms in Linux desktops; it later became a staple for system services too.
systemd didn’t create D-Bus, but systemd made D-Bus dependency patterns more explicit with unit ordering, socket activation, and user services.
User runtime directories under /run/user/UID are typically created by systemd-logind when a session starts—and removed when the last session ends.
Ubuntu has shipped both dbus-daemon and alternatives (like dbus-broker in some ecosystems); what matters is the socket contract, not the implementation brand.
XDG_RUNTIME_DIR is part of the XDG Base Directory spec; it’s supposed to be user-specific, secure, and ephemeral—exactly the opposite of a random directory under /tmp.
systemctl talks to systemd over D-Bus; if systemctl can’t reach a bus, it can’t ask systemd anything, even if systemd is technically alive.
SSH sessions are not always “logind sessions” depending on PAM configuration; when they aren’t, you can lose automatic runtime dir setup and user bus availability.
Containers often don’t have a full system bus because PID 1 isn’t systemd, or because /run is isolated. This error is normal there unless you deliberately wire it up.
PolicyKit (polkit) relies on D-Bus for authorization queries; broken bus access can look like “authentication prompts never appear” or “permission denied” with no UI.

Joke #1: D-Bus is like office email—when it’s down, everyone suddenly discovers how many things they never understood were relying on it.

Field guide: isolate which “bus” you’re failing to reach

There are a few common failure shapes:

Root on a server: systemctl fails. Usually the system bus socket is missing, dbus unit is failed, or PID 1 is in a degraded/half-dead state.
Desktop user session: GNOME settings fail, gsettings breaks, systemctl --user fails. Usually XDG_RUNTIME_DIR is not set, /run/user/UID is missing, or systemd --user isn’t running.
Automation via sudo: works as your user, fails as root, or the reverse. Usually environment variables and session context are wrong.
Inside containers/CI: systemctl errors by design because there is no systemd D-Bus to talk to.

Here’s the key: the bus is a Unix socket file. If the socket isn’t there, you’re not going to “retry harder.” If it is there but your process can’t access it, you’re dealing with permissions, namespaces, or identity problems. If it’s there and accessible but replies fail, then you’re dealing with a daemon problem.

Practical tasks: commands, expected output, and decisions

These are the tasks I actually run. Each includes what the output means and what decision you make next. Run them in order until the failure mode becomes obvious. You’re not collecting logs for fun; you’re narrowing the search space.

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

Meaning: The client cannot reach its bus socket. “No such file or directory” hints at a missing socket path, not a permission issue.

Decision: Determine if this is a system bus failure (root/system scope) or user bus failure (user scope). Next: check whether you’re root and which systemctl you ran.

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

Meaning: PID 1 is systemd; systemctl should work if the system bus path is present.

Decision: If PID 1 is not systemd (common in containers), the “fix” is to avoid systemctl or run a proper init. If it is systemd, continue.

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

Meaning: The system bus socket file exists and is a socket (leading s in permissions). World-writable here is normal for the socket endpoint; access is still controlled by D-Bus policy.

Decision: If missing: focus on dbus service and early boot issues. If present: test whether dbus replies.

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

Meaning: System bus is running; the problem may be systemctl’s ability to connect to systemd (not dbus), or a namespace/permission issue.

Decision: If dbus is inactive/failed, restart it and read logs. If active, check systemd itself and the systemd private socket.

Task 5: Confirm systemd is responsive

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

Meaning: PID 1 reports healthy. If you still see “Failed to get D-Bus connection,” you may be running systemctl in an environment that can’t see /run or lacks the correct mount namespace.

Decision: If output is degraded or maintenance, go straight to journal for systemic failures. If it’s running but clients fail, suspect namespace, chroot, or filesystem issues under /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

Meaning: /run is tmpfs; it should be writable and have space/inodes. If /run is read-only or full, sockets won’t be created and you’ll get missing-bus errors.

Decision: If full/ro: fix that first (often a runaway process or a tmpfs mis-size). If healthy: continue to user-session checks if the error is user-scoped.

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

Meaning: Environment variables point to the per-user bus. If either is empty, your session is incomplete (common over sudo, cron, or broken PAM).

Decision: If unset: you must establish a proper session context or explicitly set up a user bus (prefer the former). If set: check the socket exists.

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

Meaning: The runtime dir exists, is private (0700), and the bus socket exists. Good. If /run/user/1000 is missing, your session wasn’t registered properly with logind.

Decision: If missing: jump to loginctl and PAM/logind troubleshooting. If present but wrong owner: fix ownership and investigate why it drifted (often a bad script run as 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

Meaning: Your user manager is running and reachable. If you get “Failed to connect to bus,” your user bus path or environment is broken.

Decision: If this fails but the socket exists, your environment may be lying (wrong XDG_RUNTIME_DIR) or you’re in a different namespace (common with sudo and some remote tools).

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

Meaning: logind has an active session for the user and knows where the runtime path is. If there are no sessions, your user runtime dir may not be created.

Decision: If session is missing over SSH: check PAM configuration and whether your login path uses systemd/logind. If you need background user services, consider lingering (carefully).

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

Meaning: Root’s shell has no user bus context; systemctl --user under root is not your user session. That error is expected.

Decision: Don’t “fix” this by exporting random variables into root. Use systemctl (system scope) as root, and systemctl --user as the user inside the session. If you must manage a user unit from root, use machinectl shell or runuser with proper env, or target the user manager via loginctl enable-linger and systemctl --user under that user.

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.

Meaning: logind is creating sessions. If you instead see repeated failures to create runtime dirs, that’s your smoking gun.

Decision: If logind shows errors about runtime dir or cgroups, fix those layers. Restarting dbus won’t fix “can’t create /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

Meaning: Required components exist. Missing dbus-user-session can lead to missing session bus behavior in some setups (especially minimal installs).

Decision: If missing: install the missing packages and re-login. If present: move on to PAM/logind and environment issues.

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

Meaning: PAM is configured to register sessions with systemd/logind for SSH and console logins. If missing, you can end up with no runtime dir and no user bus.

Decision: If absent for the login path you use: add it (carefully, change-controlled) and test with a new session. If present: focus on why logind still isn’t creating runtime dirs (often related to lingering, cgroup issues, or broken systemd state).

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

Meaning: Runtime dirs exist for active users. If yours disappears when you disconnect SSH, you probably don’t have lingering and you have no active session.

Decision: For background user services: consider loginctl enable-linger username. For interactive work: ensure you have a real session and avoid running session-dependent commands from non-session contexts.

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

Meaning: The user manager can survive beyond logins, keeping user services and the runtime dir available.

Decision: Use this for headless services run in user scope (sometimes CI agents, per-user podman, etc.). Don’t enable it everywhere “just in case.” That’s how you get zombie user managers eating RAM on shared hosts.

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

Meaning: The system bus responds. If systemctl still errors, you might have a broken systemd D-Bus endpoint or a mismatch in environment/namespace.

Decision: If busctl fails too: system bus is genuinely broken. If busctl works: focus on systemd connectivity and client environment.

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

Meaning: systemd’s private socket exists; systemctl uses it in some code paths. If missing, something is deeply wrong with PID 1 or /run.

Decision: If missing: treat as a systemd/runtime filesystem problem; consider a controlled reboot after extracting logs. If present: go back to scope (system vs user) and namespace issues.

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]

Meaning: Your shell is in a different mount namespace than PID 1. You might not see the real /run where the sockets live.

Decision: If namespaces differ, run diagnostics from the host namespace (or enter it) instead of “fixing” phantom paths in your isolated view.

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

Meaning: These restarts can recover a wedged logind/dbus/systemd. daemon-reexec is heavy; it re-execs PID 1 without rebooting.

Decision: Only do this after you’ve confirmed you’re not in a container and you’ve captured enough logs to explain the incident. If user sessions are broken due to logind, restarting logind can drop sessions; schedule it like you mean it.

Common mistakes: symptom → root cause → fix

1) “systemctl works as root locally, fails over SSH”

Symptom: Over SSH, systemctl returns “Failed to get D-Bus connection,” but on console it works.

Root cause: You’re in a restricted environment (forced command, chroot, toolbox), or your SSH session isn’t seeing host /run (namespace difference).

Fix: Confirm PID 1 and mount namespace; ensure your SSH path is not chrooted and has access to /run. Use Task 2 and Task 19.

2) “systemctl –user fails after sudo -i”

Symptom: You become root and try to manage user services; it fails with bus errors.

Root cause: Root does not have your user bus environment. Also, root’s user manager is not your user manager.

Fix: Run systemctl --user as the user within that session. If you must from root, use runuser -l username -c 'systemctl --user …' and ensure a proper session exists (or enable lingering).

3) “GNOME Settings won’t open; polkit prompts never appear”

Symptom: GUI actions fail silently or complain about D-Bus.

Root cause: User session bus is broken: missing XDG_RUNTIME_DIR, stale DBUS_SESSION_BUS_ADDRESS, or missing /run/user/UID/bus.

Fix: Verify Task 7/8. Log out and log back in to recreate a clean session. If it persists, check logind and PAM integration.

4) “Cron job fails with D-Bus connection errors”

Symptom: A script that uses gsettings, notify-send, or systemctl --user fails in cron.

Root cause: Cron runs without a user session and without XDG_RUNTIME_DIR.

Fix: Don’t run desktop/session commands in cron unless you create a session context. Use system services instead, or enable lingering and run a user service that doesn’t depend on GUI state.

5) “/run/user/UID exists but owned by root”

Symptom: The directory exists, but permissions are wrong; user bus errors follow.

Root cause: Someone ran a “cleanup” as root and recreated directories incorrectly, or a misbehaving script wrote to /run/user.

Fix: Log the user out (end sessions), remove the incorrect runtime directory, and let logind recreate it. If you must fix live, correct ownership and restart user manager carefully.

6) “system bus socket missing after boot”

Symptom: /run/dbus/system_bus_socket is absent; systemctl fails broadly.

Root cause: dbus.socket or dbus.service didn’t start, or /run wasn’t mounted correctly.

Fix: Validate /run mount (Task 6), then systemctl status dbus dbus.socket, and check early-boot logs.

7) “It works on the host but fails inside a container”

Symptom: systemctl and busctl fail in a container image or CI runner.

Root cause: No systemd PID 1, no system bus, or isolated /run.

Fix: Don’t use systemctl inside that container. Use the service’s native foreground process, or run a systemd-based container intentionally with the right privileges and mounts.

Three corporate mini-stories from the trenches

Mini-story #1: The incident caused by a wrong assumption

At a mid-sized company, an on-call engineer got paged for “deploy host won’t restart services.” They SSH’d in, ran sudo systemctl restart app, and hit “Failed to get D-Bus connection.” The assumption was immediate and confident: “dbus is down; restart it.”

They restarted dbus. Then logind. Then tried a daemon-reexec. The host became harder to access, and a few interactive sessions dropped. The app was still not restarting. The incident grew legs.

The actual problem was mundane: the engineer wasn’t on the host. They were in a maintenance chroot that the team’s rescue tooling used for disk work. That environment had a different mount namespace and a different /run. Of course /run/dbus/system_bus_socket didn’t exist there; the bus socket lived in the host namespace.

Once they exited the chroot and ran the same command in the real host environment, systemctl worked immediately. The “D-Bus outage” was a mirage created by context. The fix was to add a clear shell banner for rescue environments and to teach the team to run Task 2 and Task 19 before touching daemons.

Mini-story #2: The optimization that backfired

Another team wanted faster login times and fewer background processes on developer workstations. Someone decided to “simplify” by stripping packages from the base image, including session-related components they believed were “desktop fluff.”

The image shipped, and it was fast. For about a week. Then came the tickets: IDE integration failing, password prompts not appearing, settings toggles doing nothing, and a weird one—user services failing only after reconnecting through remote desktop.

They’d removed pieces that indirectly ensured a stable user session bus. The system bus still existed, but per-user session infrastructure was inconsistent across login methods. Some logins created /run/user/UID properly; others didn’t, because PAM hooks were incomplete and user-session packages weren’t present.

The optimization wasn’t “wrong” because it saved CPU. It was wrong because it removed the scaffolding that makes the user bus predictable. The rollback added the needed packages and standardized login paths. Login time increased slightly, and the incident rate dropped dramatically. Sometimes “fast” is just “fragile with better marketing.”

Mini-story #3: The boring but correct practice that saved the day

In a regulated environment, a team ran Ubuntu servers that occasionally needed emergency console work. They had a policy that felt old-fashioned: every incident response starts with capturing state, including journalctl -b excerpts and a snapshot of /run socket paths, before any restarts.

It sounded bureaucratic until a production host began throwing D-Bus connection errors after a kernel update. The on-call followed the policy. They captured findmnt /run, checked free space, verified /run/systemd/private existed, and noted that /run/dbus/system_bus_socket was missing. They also captured early-boot logs showing tmpfs mount warnings.

Because they had evidence, they didn’t thrash. They found that /run was mounted read-only due to a subtle initramfs/mount failure. With that corrected and a controlled reboot, the bus socket appeared, systemctl recovered, and the outage ended cleanly.

The boring practice didn’t just fix the machine; it preserved the narrative. In corporate environments, the narrative is half the recovery: you need to explain what happened without blaming cosmic rays.

Checklists / step-by-step plan

Checklist A: You see “Failed to get D-Bus connection” running systemctl (system scope)

Confirm you’re on the host and PID 1 is systemd (Task 2).
Check /run mount and capacity (Task 6).
Verify /run/dbus/system_bus_socket exists (Task 3).
Check systemctl status dbus dbus.socket (Task 4).
Check systemd private socket /run/systemd/private (Task 18).
Test bus responsiveness with busctl --system list (Task 17).
Pull logs: journalctl -b and relevant units (Task 12).
If you must restart, do it deliberately: logind → dbus → daemon-reexec (Task 20).

Checklist B: You see the error running systemctl –user or desktop tools (user session scope)

Check XDG_RUNTIME_DIR and DBUS_SESSION_BUS_ADDRESS (Task 7).
Verify /run/user/UID and /run/user/UID/bus exist and are owned by the user (Task 8).
Check systemctl --user status (Task 9).
Use loginctl list-sessions and loginctl show-user (Task 10).
If this is SSH/cron, decide: do you need a real session or a system service instead?
If you need background user services, enable lingering for that user (Task 16), then re-test.
If the runtime dir keeps disappearing, fix session lifecycle and PAM (Task 14/15).

Checklist C: You’re in automation/CI and it fails

Confirm whether you are in a container and PID 1 is not systemd (Task 2).
Stop trying to use systemctl in that environment. Run the service directly, or redesign the job.
If you truly require systemd, run a systemd-capable environment intentionally, not accidentally.

Joke #2: Restarting dbus without checking sockets is like rebooting a printer because you’re out of paper—cathartic, ineffective, and oddly popular.

FAQ

1) Why does `systemctl` use D-Bus at all?

systemctl is a client. It talks to systemd’s manager APIs, commonly exposed over D-Bus and systemd’s private socket. No bus, no conversation.

2) I can see `dbus-daemon` running. Why do I still get the error?

Because the daemon process existing is not the same as the socket being reachable in your namespace/context. Check the socket paths under /run and confirm you’re in the host mount namespace (Task 3, 6, 19).

3) What does “No such file or directory” vs “Permission denied” change?

No such file usually means the socket path doesn’t exist in your view (missing /run mount, missing runtime dir, namespace issue). Permission denied means the socket exists but access control blocks you (wrong user, policy, or confinement).

4) Why does it break only over SSH?

Either your SSH session isn’t registered with logind (PAM misconfiguration), or you’re executing within a restricted wrapper/chroot. Verify pam_systemd.so and check whether /run/user/UID is created for that session (Task 10, 14).

5) Is enabling lingering safe?

It’s safe when you know why you need it: running user services without active logins. It’s unsafe as a blanket workaround because you’ll keep user managers alive, which can hide logout bugs and waste resources. Enable it per-user, deliberately (Task 16).

6) Can I just export `DBUS_SESSION_BUS_ADDRESS` and move on?

You can, but you shouldn’t. Exporting stale addresses is how you create “works on my shell” ghosts that break later. Prefer establishing a real session and letting logind/systemd set XDG_RUNTIME_DIR and the bus address.

7) What’s the quickest way to tell system bus vs user bus?

If you’re using systemctl without --user, it’s system scope. If the relevant socket is /run/dbus/system_bus_socket, it’s system bus. If it’s /run/user/UID/bus, it’s user session bus.

8) I’m in a minimal server install—do I need `dbus-user-session`?

If you run user-scoped services or expect user sessions to have a proper session bus, yes, it’s often necessary. If you only manage system services, you can sometimes avoid it. The symptom-driven answer: if user bus is missing, check package presence (Task 13).

9) Why does `systemctl --user` fail as root even when the user is logged in?

Because root’s environment is not the user’s environment, and root is not “attached” to that user session bus. Run the command as the user in the session, or use appropriate tooling to target that user manager.

10) When do I reboot instead of debugging?

If PID 1 is unhealthy, /run is corrupted/read-only, or systemd sockets are missing and you can’t recover them cleanly, a controlled reboot is often the most reliable fix. Capture logs first.

Conclusion: next steps you can ship today

“Failed to get D-Bus connection” is not an invitation to restart random services. It’s a request to verify a contract: /run is mounted and writable, the right socket exists, your session is real, and your environment points at the correct bus.

Do these next:

Run the fast playbook: sockets, runtime dirs, logind sessions. Don’t skip to restarts.
Decide whether your workflow depends on the user bus. If it does, standardize login paths (PAM + logind) and avoid cron for session work.
If this is a fleet issue, add a lightweight health check: verify /run/dbus/system_bus_socket and /run/systemd/private exist, and alert on missing runtime dirs for active sessions.
Write down the context rule: chroots/containers are allowed to fail systemctl. Your runbooks should say that out loud.