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
Task Type Bug Report
Category Packages
Status Closed
Assigned To Sergej Pupykin (sergej)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 9
Private No

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
Comment by Dave Reisner (falconindy) - Thursday, 03 March 2016, 23:33 GMT
> However, I think the root problem here is that the systemd compat libs should never have been removed in the first place.
The compat libs no longer exist in upstream systemd. This must be fixed in libvirt.
Comment by Dave Reisner (falconindy) - Thursday, 03 March 2016, 23:52 GMT
Looking deeper into this, I'm rather lost. You mention libvirtd.service, so starting from there, it's a service which launches /usr/bin/libvirtd. I download the latest libvirt package, extract it, and...

$ 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?
Comment by Richard Tollerton (rtollert) - Friday, 04 March 2016, 17:47 GMT
> The compat libs no longer exist in upstream systemd.

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.
Comment by Richard Tollerton (rtollert) - Friday, 04 March 2016, 18:12 GMT Comment by deusstultus (deusstultus) - Friday, 04 March 2016, 22:53 GMT
Patch attached per rtollert's callout in upstream report from debian fix. Successfully resolves in Arch Linux before upstream fix, PKGBUILD changes pushed at https://github.com/deusstultus/Archlinux_packages/commit/e2d63d45ba33edc69fcbf21aa8491de3ba45712a with patchfile sourced from debian build sources https://packages.debian.org/stretch/libvirt-dev
Comment by Bronek Kozicki (bronek) - Sunday, 06 March 2016, 16:29 GMT
@deusstultus thank you for this patch, it fixed the issue for me (libvirtd was continuously restarting after upgrade to systemd 229)

Loading...