See my askubuntu question here:
I did sudo apt-get dist-upgrade today and noticed an error:
Processing triggers for dbus (1.10.6-1ubuntu3.3) ...
Failed to open connection to "system" message bus: Failed to connect to socket /usr/local/pyenv/versions/miniconda2-latest/var/run/dbus/system_bus_socket: No such file or directory
Updating another server was fine. I think the difference is that on the first server, I installed pyenv to /usr/local, and activated it for all users in /etc/profile.d. Somehow dbus depends on system python to function.
I am aware that installing pyenv to all users is risky. My questions are:
How serious is this dbus error? Can I ignore it or fix it?
Any means to prevent this happening again without removing pyenv?
Can dbus become immune to pyenv setup?
Update: the dbus error made my ssh login slow, same as this: ssh connection takes forever to initiate, stuck at “pledge: network”. I was unable to fix it by systemctl commands. A sudo reboot did.
Thank you in advance.
I am using ubuntu 16.04.
(In reply to Yi from comment #0)
> Processing triggers for dbus (1.10.6-1ubuntu3.3) ...
> Failed to open connection to "system" message bus: Failed to connect to
> No such file or directory
This is the bug tracking system for upstream dbus, not for any particular Linux distribution; but I happen to be the maintainer of dbus in Debian, so I know that the dbus.postinst maintainer script uses dbus-send to ask the system dbus-daemon (dbus-daemon --system) to reload its configuration. That is what is failing here.
It looks as though a pyenv environment for miniconda2 (whatever that is) may have configured your environment to include a separate D-Bus system bus that is not actually system-wide (and is also not running), and set DBUS_SYSTEM_BUS_ADDRESS to point to that. This means that instead of asking the "real" system bus to reload, the dbus-send command run by dbus.postinst will ask a nonexistent miniconda2 system bus to reload. That doesn't work because it isn't running; it also doesn't do what it is meant to, which is to ask the "real" system bus to reload.
Is DBUS_SYSTEM_BUS_ADDRESS set to /usr/local/pyenv/versions/miniconda2-latest/var/run/dbus/system_bus_socket, either globally or in the shell where you ran the upgrade? And have you configured sudo to pass random environment variables through to the command, by disabling the env_reset option?
Please run sysadmin activities like upgrading in a shell that does not have similar environment changes. One convenient way to do this might be to use sudo with the env_reset option enabled (so the root command does not inherit the environment from the user shell), which is the upstream and Debian default.
> Somehow dbus depends on system python to function.
I can assure you that dbus does not depend on any version of Python.
The Debian packaging for the system-wide installation of dbus does depend on you not having set environment variables that change standard tools' behaviour, for example redirecting its concept of what the address of the system bus ought to be.
> I am aware that installing pyenv to all users is risky.
Yes. If it is broken, you get to keep both pieces. Upstream projects are not generally going to debug this sort of issue for you.
> Can dbus become immune to pyenv setup?
The fact that it's possible to override the system bus address with an environment variable is a feature, not a bug. You have chosen to override it, and now you have to cope with the consequences of doing so.
dbus.postinst could forcibly unset DBUS_SESSION_BUS_ADDRESS, but if we did that, where would we stop? Do we need to reset LD_LIBRARY_PATH? Do we need to reset PATH to a normal value? And so on. If every maintainer script had to have a list of environment variables to reset (and reasonable values to reset them to), that would scale incredibly badly.
A better solution is to avoid running system-level things with special environment variables like those set.
I would strongly recommend doing system-level activities (such as upgrading) from a shell that is not affected by pyenv environment variables.
This is not a dbus upstream bug. I don't think it's a dbus Ubuntu bug either; I think the problem is with your server's local configuration.
Thank you, Simon, for your prompt, thorough and considerate reply. I really appreciate it. I will follow what you explained and advised to check my environment configuration and adjust it accordingly.
(In reply to Simon McVittie from comment #1)