On Thu, Aug 20, 2020 at 11:42:45AM -0600, Jim Fehlig wrote: > On 8/20/20 10:54 AM, Mark Mielke wrote: > > On Thu, Aug 20, 2020 at 11:48 AM Christian Ehrhardt > > <christian.ehrhardt@xxxxxxxxxxxxx > > <mailto:christian.ehrhardt@xxxxxxxxxxxxx>> wrote: > > > > On Thu, Aug 20, 2020 at 5:15 PM Mark Mielke <mark.mielke@xxxxxxxxx > > <mailto:mark.mielke@xxxxxxxxx>> wrote: > > > On Thu, Aug 20, 2020 at 8:55 AM Christian Ehrhardt > > <christian.ehrhardt@xxxxxxxxxxxxx <mailto:christian.ehrhardt@xxxxxxxxxxxxx>> > > wrote: > > >> This was meant for upgrades, but if libvirt would define a known path in > > >> there like /var/run/qemu/last_packaging_change the packages could easily > > >> touch it on any install/remove/update as Daniel suggested and libvirt could > > >> check this path like it does with the date of the qemu binary already. > > > Earlier in this thread - I think one or two of us had asked about the > > timestamp on the directory that contains the modules. > > > I'm wondering if a "last_packaging_change" provides any value over and > > above the timestamp of the directory itself? Wouldn't the directory be best > > - as it would work automatically for both distro packaging as well as custom > > installs? > > Sure, if > > - "list of files in module dir" > > - "stat dates of files in module dir" > > would be checked by libvirt that would also be a no-op for packaging > > and thereby land faster. > > > > > > Why is the list of files and stat dates needed? Any change done by RPM > > to add or remove a file from the directory, should cause the mtime for > > the directory to be updated. It doesn't really matter what the change is > > - it only matters that the change is detected. > > > > The case for needing to check the files *in* the directory, would be a > > concern about the modules keeping the same name, but being updated in > > place. I'm doubtful that this ever occurs for real, as it would cause > > breakage for running programs. Existing running programs would mmap() or > > similar the binaries into memory, and cannot be updated in place. > > Instead, the inode remains alive, and a new file is created with the > > same name, to replace the old file, and once all file descriptors are > > closed - the inode is deleted. > > > > So, unless there is a hierarchical directory structure - I believe > > checking the modules directory timestamp is near 100% accuracy for > > whether modules were added, removed, or updated using "safe" deployment > > practices either by RPM or "make install". > > I wrote a small test program that checks mtime (also tried ctime) and it > only changes on the directory when files are added and deleted. There is no > change to either if a file in the directory has been updated. It would be > really convenient to check only the directory to see if its' contents have > changed but I'm not aware of how to do that other than with something like > inotify. Suggestions welcomed. IIUC, Mark's point is that an RPM update won't replace the file in-placec. It will write out a new temporary file and then rename over the top of the old file, which should trigger an update on the directory mtime. Not sure what a "make install" will do with QEMU, but since QEMU is about to switch to meson, we might get lucky in having the same temp+rename behaviour. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
