FS#48440 - [libvirtd] still depends on systemd-compat-libs
Attached to Project:
Community Packages
Opened by Richard Tollerton (rtollert) - Thursday, 03 March 2016, 22:43 GMT
Last edited by Sergej Pupykin (sergej) - Thursday, 10 March 2016, 17:40 GMT
Opened by Richard Tollerton (rtollert) - Thursday, 03 March 2016, 22:43 GMT
Last edited by Sergej Pupykin (sergej) - Thursday, 10 March 2016, 17:40 GMT
|
Details
Description:
After the systemd 229 upgrade, libvirtd.service is in a continuous restart loop. (I don't have any logs, because journalctl is coredumping when viewing the logs from past boots.) In the process, systemd appears to also be killing autostarted VMs, which could engender some risk of VM disk corruption. This is because libvirt is still relying on libsystemd-daemon in order to call sd_notify(). However, libsystemd-daemon got removed in systemd 229-1 (https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/systemd&id=c91d52bcf82e197f3ea217893e20e45e43f933b7). Debian fixed this issue last August (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=779775) but did not upstream their fix. Hand-applying the patch to libvirt 1.3.2 fixes the issue. However, I think the root problem here is that the systemd compat libs should never have been removed in the first place. |
This task depends upon
Closed by Sergej Pupykin (sergej)
Thursday, 10 March 2016, 17:40 GMT
Reason for closing: Fixed
Additional comments about closing: patch applied
Thursday, 10 March 2016, 17:40 GMT
Reason for closing: Fixed
Additional comments about closing: patch applied
The compat libs no longer exist in upstream systemd. This must be fixed in libvirt.
$ readelf -d libvirtd | awk '/NEEDED/ && /systemd/'
No output. Let's try recursing through the deps...
$ ldd libvirtd | grep systemd
libsystemd.so.0 => /usr/lib/libsystemd.so.0 (0x00007fdd4f1e9000)
...but that's linked correctly to libsystemd through something else. What's that dependency chain?
libvirtd => /usr/lib/libavahi-client.so.3 => /usr/lib/libdbus-1.so.3 => /usr/lib/libsystemd.so.0
So... your dbus binary is wrongly linked? Did you perform some partial upgrade? Is there something you've not mentioned?
Thanks for pointing that out, although I would like to clarify that the "upstream" is v229 release, not git master. I don't think it's logical to disable a feature in v229 because it's disabled in a future release (and *present* in v229).
> This must be fixed in libvirt.
I agree, and I'll try to make sure they know about this, but that's no excuse for dropping the compat libs without warning. Warnings have been posted on the Arch homepage for *far* more minor compatibility concerns. (Exhibit A: C++5 ABI changes.)
At this point, given the changes in systemd git, all I'm asking for is a warning on the Arch homepage.
The rest of this discussion is probably moot, but just to clean up loose threads:
> $ ldd libvirtd | grep systemd
> libsystemd.so.0 => /usr/lib/libsystemd.so.0 (0x00007fdd4f1e9000)
>
> ...but that's linked correctly to libsystemd through something else. What's that dependency chain?
>
> libvirtd => /usr/lib/libavahi-client.so.3 => /usr/lib/libdbus-1.so.3 => /usr/lib/libsystemd.so.0
No, the dependency chain must go through /usr/lib/libvirt.so.0, because that's what is referencing sd_notify, not /usr/bin/libvirtd.
> So... your dbus binary is wrongly linked? Did you perform some partial upgrade? Is there something you've not mentioned?
Nope -- looks like the current libvirt package are just busted. It didn't detect libsystemd-daemon, so it doesn't use it, even though it's still set to Type=notify in /usr/lib/systemd/system/libvirtd.service.
# hand-hacked libvirt package to use libsystemd instead of libsystemd-daemon:
$ nm -Du /usr/lib/libvirt.so.0 | grep sd
U sd_notify
$
# Current libvirt package:
$ nm -Du libvirt.so.0 | grep sd
$
Again, I'm not disputing that this is an issue that must be fixed in libvirtd -- but it's only the penultimate problem, not the root cause.