Your message dated Fri, 5 Jan 2018 11:04:18 +0000 with message-id <[email protected]> and subject line Re: Bug#886325: dbus daemon does not start with error "undefined symbol: XML_SetHashSalt" has caused the Debian Bug report #886325, regarding dbus daemon does not start with error "undefined symbol: XML_SetHashSalt" to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 886325: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886325 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: dbus Version: 1.10.24-0+deb9u1 Severity: grave Justification: renders package unusable I'm working on Debian stable. After a small update and a reboot, dbus daemon does not start with the following message: systemd[1]: Started D-Bus System Message Bus. dbus-daemon[1350]: /usr/bin/dbus-daemon: symbol lookup error: /usr/bin/dbus-daemon: undefined symbol: XML_SetHashSalt amaltea systemd[1]: dbus.service: Main process exited, code=exited, status=127/n/a amaltea systemd[1]: dbus.service: Unit entered failed state. amaltea systemd[1]: dbus.service: Failed with result 'exit-code' Starting manually same result: # DBUS_VERBOSE=1 dbus-daemon --session --print-address dbus-daemon: symbol lookup error: dbus-daemon: undefined symbol: XML_SetHashSalt Other services depend on it, therefore the machine is unusable. I tried to upgrade expat and libexpat1 packages from testing. libexpat1 depends on libc6 >= 2.25, no upgrade possible. The versions of packages are: ii dbus 1.10.24-0+deb9u1 ii expat 2.2.5-3 (was 2.2.0) ii libexpat1:amd64 2.2.0-2+deb9u1 -- System Information: Debian Release: 9.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-4-amd64 (SMP w/24 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages dbus depends on: ii adduser 3.115 ii init-system-helpers 1.48 ii libapparmor1 2.11.0-3 ii libaudit1 1:2.6.7-2 ii libc6 2.24-11+deb9u1 ii libcap-ng0 0.7.7-3+b1 ii libdbus-1-3 1.10.24-0+deb9u1 ii libexpat1 2.2.0-2+deb9u1 ii libselinux1 2.6-3+b3 ii libsystemd0 232-25+deb9u1 ii lsb-base 9.20161125 dbus recommends no packages. Versions of packages dbus suggests: pn default-dbus-session-bus | dbus-session-bus <none> Versions of packages dbus is related to: pn dbus-x11 <none> ii systemd 232-25+deb9u1 ii systemd-sysv 232-25+deb9u1 -- no debconf information
--- End Message ---
--- Begin Message ---notfound 886325 1.10.24-0+deb9u1 thanks On Fri, 05 Jan 2018 at 09:40:44 +0100, Alberto Brosich wrote: > On Thu, 2018-01-04 at 18:28 +0000, Simon McVittie wrote: > > Do you have an outdated copy of libexpat.so.1 > > in /usr/local/lib or some similar location? > > ldd showed that dbus-daemon used an old libexpat1 of another software. Closing the bug, then. > I changed the order in /etc/ld.so.conf.d and now all works fine. If you have other software that needs a private copy of libraries that are also installed system-wide, please arrange for those libraries to be used by that software and not by the rest of the system. You could use a container or chroot for the programs that need private libraries, or link those programs with -rpath, or set the LD_LIBRARY_PATH environment variable for those programs (but not for the rest of the system); but you should avoid putting private libraries in the global search path configured by /etc/ld.so.conf.d. > I do not know why it happened because the machine is very stable and I > apply only security updates The use of XML_SetHashSalt() was only added recently (it turns off a libexpat change that could result in dbus-daemon taking so long to start that it breaks the boot process on entropy-starved systems). In Debian 9 'stretch' this change was introduced in Debian 9.3. Point releases like 9.3 contain fixes for selected non-security bugs, not just security fixes. smcv
--- End Message ---
