Client failed to connect to the D-BUS daemon. Failed to connect to socket /tmp/dbus-<something>: Connection refused

I'm seeing the error, as listed in the title, quite often.

I'm using Linux Mint, a couple different versions (18.3 and 21.1 to be precise).

I'm running applications, from the command-line, on a VM (under Hyper-V, if it matters) and actually driving them from an X-server on a different machine (thin client). I start the VM, which starts X-Windows, then use sudo to kill lightdm (which kills X-Windows to save resources). Then I login, in text mode, and run xterm from the command-line, pointing the display variable to my thin client. This gives me an xterm window on my thin client, from which I can run the apps on the VM and interact with them on the thin client.

But I routinely get that error message. All day long. This happens with gvim, firefox, chromium, you name it.

If I run X-Windows in the VM and run the applications from the command-line there, I do NOT get this error. It ONLY happens when I'm running the VM in text mode and using X-Windows on a thin client.

The apps still work. They behave (mostly) normally. But I get that error message every time.

When running gvim, I always get that message and I get an additional pop-up saying that "An error occurred while loading or saving configuration information for gvim. Some of your configuration settings may not work properly." I'm not noticing anything out of the ordinary with gvim's behavior. But having to kill that pop-up all the time is a pain. I use gvim dozens of time on any given day. I get the error and the pop-up every time.

Additionally, when I start chromium in this fashion, it fails to remember any of my usernames and passwords (not ENTIRELY normal operation).

I've been looking at all the other entries for this error message. I've tried various things but none of them are clearing the problem for me.

Yes, dbus and dbus-x11 are installed.

Running dbus-launch gives me some status info but has no effect.

If I run service dbus status, it tells me that it is active. Running service dbus start asks for passwords (as if I were doing something under a sudo) to start "dbus.socket" and "dbus.service" but I still get the errors afterwards, so those don't appear to be accomplishing anything.

While I use sudo to kill lightdm, I do NOT use sudo for anything else. I have a user account in the VM, with which I login (in text mode), start xterm and run all the apps. So this should NOT be a perms issue.

Suggestions on what else to try? This is, mostly, an annoyance but I'd like to get my config to a point where this isn't an issue at all.

Run your xterm as a child of dbus-launch:

dbus-launch [--exit-with-session] xterm &         (older)

dbus-run-session xterm &                          (newer)

Alternatively:

If Mint is anything like Debian &ndash; install the dbus-user-session package, which will cause a session bus to always be started at a fixed location for all login types (including text console and SSH logins). The "user" bus would be controlled through a "user service":

systemctl --user status dbus

(Note &ndash; since the "user" bus continues to exist independently of the X display, after switching $DISPLAY you would need to run:

dbus-update-activation-environment --systemd DISPLAY

to re-import environment to the running dbus-daemon and systemd --user processes.)

> Running dbus-launch gives me some status info but has no effect.

Its effect that you haven't noticed is that dbus-launch starts a dbus-daemon instance in background; the "status info" is the address of the new bus that your apps are supposed to connect to. The output is meant to be eval'd, so that the new DBUS_SESSION_BUS_ADDRESS would replace the stale one that's currently in your environment (or in the ~/.dbus cached "autolaunch" data).

Very similar to ssh-agent, if you do not specify a "child" command to run, the usage would be:

eval "$(dbus-launch)"

This usage tends to leave stale dbus-daemon processes lingering around, unless --exit-with-x11 or --exit-with-session is added.

> If I run X-Windows in the VM and run the applications from the command-line there, I do NOT get this error

You do not get this error because the graphical session has run dbus-launch during login (likely as part of the dbus-x11 scripts) and has put the correct DBUS_SESSION_BUS_ADDRESS in the environment. Killing the X server causes dbus-launch to kill the dbus-daemon, so the address no longer has anything listening.

> If I run service dbus status, it tells me that it is active.

That's the wrong bus. dbus.service represents the global "system" bus; your error messages are looking for the per-user "session" bus.