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@xxxxxxxxxx> > --- > 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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list