On Wed, May 20, 2015 at 08:52:56AM -0400, John Ferlan wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=1195882
Force re-reading of the capabilities cache upon new installations.
Since re-reading of the capabilities is based on the 'ctime' of either
the QEMU binary or if the new libvirtd is greater than what created the
cache file, it's possible that depending on the order of installations
that a later date created "backported" libvirtd could create the cache
file while followup installation of a mainline release that had an
earlier creation date wouldn't cause the cache to be updated. This
results in the possibility that (a) feature(s) in the mainstream
release wouldn't be available unless someone delete the cache by hand.
Signed-off-by: John Ferlan <jferlan(a)redhat.com>
---
libvirt.spec.in | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/libvirt.spec.in b/libvirt.spec.in
index 4195518..e28f737 100644
--- a/libvirt.spec.in
+++ b/libvirt.spec.in
@@ -1705,6 +1705,10 @@ fi
/sbin/chkconfig --add virtlockd
%endif
+# Remove any files in the capabilities cache to force the daemon
+# to start fresh
+rm -rf %{_localstatedir}/cache/libvirt/qemu/capabilities
This is going to be racey. You are removing the cache while the
existing libvirtd is still running. Some time later RPM will
tell systemd to restart libvirtd. Between those points in time
the old libvirtd may have re-generated the cache.
Regards,
Daniel
--
|:
http://berrange.com -o-
http://www.flickr.com/photos/dberrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|:
http://entangle-photo.org -o-
http://live.gnome.org/gtk-vnc :|