Hi folks,
after upgrading a Centos container (LXC) from 7.4 to 7.5 I got this:
# systemctl status Failed to get D-Bus connection: Connection refused
# busctl Failed to connect to bus: Connection refused
# ps -ef | grep db[u]s dbus 55 1 0 Jul02 ? 00:00:00 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
# lsof -p 55 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME dbus-daem 55 dbus cwd DIR 8,4 4096 130819 / dbus-daem 55 dbus rtd DIR 8,4 4096 130819 / dbus-daem 55 dbus txt REG 8,4 223344 133569 /usr/bin/dbus-daemon dbus-daem 55 dbus DEL REG 8,4 393485 /var/lib/sss/mc/initgroups dbus-daem 55 dbus mem REG 8,4 37240 150982 /usr/lib64/libnss_sss.so.2 dbus-daem 55 dbus mem REG 8,4 62184 150786 /usr/lib64/libnss_files-2.17.so dbus-daem 55 dbus mem REG 8,4 68192 141459 /usr/lib64/libbz2.so.1.0.6 dbus-daem 55 dbus mem REG 8,4 90664 140578 /usr/lib64/libz.so.1.2.7 dbus-daem 55 dbus mem REG 8,4 99944 150835 /usr/lib64/libelf-0.170.so dbus-daem 55 dbus mem REG 8,4 19896 140110 /usr/lib64/libattr.so.1.1.0 dbus-daem 55 dbus mem REG 8,4 402384 132708 /usr/lib64/libpcre.so.1.2.0 dbus-daem 55 dbus mem REG 8,4 88776 150757 /usr/lib64/libgcc_s-4.8.5-20150702.so.1 dbus-daem 55 dbus mem REG 8,4 19776 150776 /usr/lib64/libdl-2.17.so dbus-daem 55 dbus mem REG 8,4 297360 151443 /usr/lib64/libdw-0.170.so dbus-daem 55 dbus mem REG 8,4 106848 150792 /usr/lib64/libresolv-2.17.so dbus-daem 55 dbus mem REG 8,4 19384 141564 /usr/lib64/libgpg-error.so.0.10.0 dbus-daem 55 dbus mem REG 8,4 535064 141290 /usr/lib64/libgcrypt.so.11.8.2 dbus-daem 55 dbus mem REG 8,4 85952 150956 /usr/lib64/liblz4.so.1.7.5 dbus-daem 55 dbus mem REG 8,4 157424 140323 /usr/lib64/liblzma.so.5.2.2 dbus-daem 55 dbus mem REG 8,4 44448 150794 /usr/lib64/librt-2.17.so dbus-daem 55 dbus mem REG 8,4 1139680 150778 /usr/lib64/libm-2.17.so dbus-daem 55 dbus mem REG 8,4 20032 140130 /usr/lib64/libcap.so.2.22 dbus-daem 55 dbus mem REG 8,4 2173512 146385 /usr/lib64/libc-2.17.so dbus-daem 55 dbus mem REG 8,4 144792 144798 /usr/lib64/libpthread-2.17.so dbus-daem 55 dbus mem REG 8,4 23968 141464 /usr/lib64/libcap-ng.so.0.0.0 dbus-daem 55 dbus mem REG 8,4 127096 146315 /usr/lib64/libaudit.so.1.0.0 dbus-daem 55 dbus mem REG 8,4 155784 150814 /usr/lib64/libselinux.so.1 dbus-daem 55 dbus mem REG 8,4 173320 140201 /usr/lib64/libexpat.so.1.6.0 dbus-daem 55 dbus mem REG 8,4 203800 151456 /usr/lib64/libsystemd.so.0.6.0 dbus-daem 55 dbus mem REG 8,4 333408 144514 /usr/lib64/libdbus-1.so.3.14.14 dbus-daem 55 dbus mem REG 8,4 164240 150767 /usr/lib64/ld-2.17.so dbus-daem 55 dbus 0u CHR 1,3 0t0 129677343 /dev/null dbus-daem 55 dbus 1u unix 0xffff8f56b7b2cc00 0t0 129677608 socket dbus-daem 55 dbus 2u unix 0xffff8f56b7b2cc00 0t0 129677608 socket dbus-daem 55 dbus 3u unix 0xffff8f56bbbb3800 0t0 129676115 /run/dbus/system_bus_socket dbus-daem 55 dbus 4u a_inode 0,11 0 8547 [eventpoll] dbus-daem 55 dbus 5r REG 8,4 10406312 393485 /var/lib/sss/mc/initgroups (deleted) dbus-daem 55 dbus 6u sock 0,8 0t0 129677256 protocol: NETLINK dbus-daem 55 dbus 7r a_inode 0,11 0 8547 inotify dbus-daem 55 dbus 8u unix 0xffff8f56b80c4c00 0t0 129677257 socket dbus-daem 55 dbus 9u unix 0xffff8f56ba3aec00 0t0 129677258 socket dbus-daem 55 dbus 10u unix 0xffff8f56b7681000 0t0 129681025 /run/dbus/system_bus_socket
Please note the "/run/dbus/system_bus_socket". AFAICT thats new. Shouldn't it listen on /var/run/dbus/system_bus_socket for backward compatibility as well?
Is there is a way to fix this? Every helpful comment is highly appreciated. Harri
On 07/03/2018 02:16 AM, Harald Dunkel wrote:
Please note the "/run/dbus/system_bus_socket". AFAICT thats new. Shouldn't it listen on /var/run/dbus/system_bus_socket for backward compatibility as well?
Yes and no.
$ ls -ld /var/run lrwxrwxrwx. 1 root root 6 Dec 13 2017 /var/run -> ../run/
After a manual fix I have that, too. Point is that for historic hosts this symlink doesn't exist. The upgrade fails due to dbus becoming unavailable. And the next reboot fails, too, because the symlink is not created automatically.
Can you confirm this?
Regards Harri
On Thu, Jul 05, 2018 at 11:26:28AM +0200, Harald Dunkel wrote:
After a manual fix I have that, too. Point is that for historic hosts this symlink doesn't exist. The upgrade fails due to dbus becoming unavailable. And the next reboot fails, too, because the symlink is not created automatically.
Can you confirm this?
The /var/run symlink to /run is part of the 'filesystem' package, and has existed as a symlink since 7.0.1406 was released:
$ rpmls -l http://vault.centos.org/7.0.1406/os/x86_64/Packages/filesystem-3.2-18.el7.x8... |grep /var/run lrwxrwxrwx root root /var/run
On 05/07/2018 14:18, Jonathan Billings wrote:
The /var/run symlink to /run is part of the 'filesystem' package, and has existed as a symlink since 7.0.1406 was released:
$ rpmls -l http://vault.centos.org/7.0.1406/os/x86_64/Packages/filesystem-3.2-18.el7.x8... |grep /var/run lrwxrwxrwx root root /var/run
I've never seen "rpmls". Is it an actual command, or your personal alias? I would have done:
rpm -qlvp http://vault.centos.org/7.0.1406/os/x86_64/Packages/filesystem-3.2-18.el7.x8... |grep /var/run
Regards, Anand
On Thu, 5 Jul 2018, Anand Buddhdev wrote:
I would have done:
rpm -qlvp http://vault.centos.org/7.0.1406/os/x86_64/Packages/filesystem-3.2-18.el7.x8... |grep /var/run
And you would have seen that it does provide it?
jh
On Thu, Jul 05, 2018 at 02:25:58PM +0200, Anand Buddhdev wrote:
I've never seen "rpmls". Is it an actual command, or your personal alias? I would have done:
Sorry, rpmls is part of the rpmdevtools package. It's the equivalent to running:
rpm -q --qf="[%-11{filemodes:perms} %-8{fileusername} %-8{filegroupname} $owner%{filenames}\n]" http://vault.centos.org/7.0.1406/os/x86_64/Packages/filesystem-3.2-18.el7.x8...
On Thu, Jul 05, 2018 at 08:18:08AM -0400, Jonathan Billings wrote:
The /var/run symlink to /run is part of the 'filesystem' package, and has existed as a symlink since 7.0.1406 was released:
$ rpmls -l http://vault.centos.org/7.0.1406/os/x86_64/Packages/filesystem-3.2-18.el7.x8... |grep /var/run lrwxrwxrwx root root /var/run
More specifically, the 'filesystem' package creates and symlinks the /var/run directory as part of the pretrans scriptlet (which is a lua script):
$ rpm -q --scripts http://vault.centos.org/7.0.1406/os/x86_64/Packages/filesystem-3.2-18.el7.x8...
pretrans scriptlet (using <lua>): --# If we are running in pretrans in a fresh root, there is no /usr and --# symlinks. We cannot be sure, to be the very first rpm in the --# transaction list. Let's create the needed base directories and symlinks --# here, to place the files from other packages in the right locations. --# When our rpm is unpacked by cpio, it will set all permissions and modes --# later. posix.mkdir("/usr") posix.mkdir("/usr/bin") posix.mkdir("/usr/sbin") posix.mkdir("/usr/lib") posix.mkdir("/usr/lib/debug") posix.mkdir("/usr/lib/debug/usr") posix.mkdir("/usr/lib64") posix.symlink("usr/bin", "/bin") posix.symlink("usr/sbin", "/sbin") posix.symlink("usr/lib", "/lib") posix.symlink("usr/bin", "/usr/lib/debug/bin") posix.symlink("usr/lib", "/usr/lib/debug/lib") posix.symlink("usr/lib64", "/usr/lib/debug/lib64") posix.symlink("../.dwz", "/usr/lib/debug/usr/.dwz") posix.symlink("usr/sbin", "/usr/lib/debug/sbin") posix.symlink("usr/lib64", "/lib64") posix.mkdir("/run") posix.symlink("../run", "/var/run") posix.symlink("../run/lock", "/var/lock") return 0 posttrans scriptlet (using /bin/sh): #/bin/sh dependency should not be problem for posttrans #we need to restorecon on some dirs created in %pretrans or by other packages restorecon /var/run 2>/dev/null >/dev/null || : restorecon /var/lock 2>/dev/null >/dev/null || : restorecon -r /usr/lib/debug/ 2>/dev/null >/dev/null || : restorecon /sys 2>/dev/null >/dev/null || : restorecon /boot 2>dev/null >/dev/null || : restorecon /proc 2>dev/null >/dev/null || : restorecon /dev 2>dev/null >/dev/null || :