On Thu, Apr 02, 2020 at 02:51:13PM +0200, Andrea Bolognani wrote: > On Thu, 2020-04-02 at 13:36 +0100, Daniel P. Berrangé wrote: > > On Thu, Apr 02, 2020 at 02:20:27PM +0200, Andrea Bolognani wrote: > > > On Thu, 2020-04-02 at 13:10 +0100, Daniel P. Berrangé wrote: > > > > virLogDaemonInhibitor only inhibits timer shutdown for the unprivileged > > > > daemon. This setting a timeout will cause the virtlogd to shutdown even > > > > when log files are open. I can't remember why I special cased this in > > > > the code now, but fairly sure we'll need to fix that first. > > > > > > If we're not convinced this is safe, then we better revert > > > 02b6005063d6 before 6.2.0 is tagged. > > > > > > > Can you test to ensure that they don't prematurely shut down when logs > > > > or locks are held. > > > > > > I have been running some variation of master (including the commit > > > mentioned above) for a while now and I haven't encountered any issues > > > with it. What exactly should I be looking for? > > > > Just run "virtlogd --timeout 20" and then start a QEMU guest. I see that > > virtlogd shuts down while the guest is still running, thus breaking the > > logfile writing. NB run the system instance, not session instance. > > I started a VM, waited a bit, and sure enough virtlogd quit on its > own. However, after I ssh'd into the VM and executed poweroff, > virtlogd was socket-activated (as expected) and the log file, which > I was tailing from another terminal, was updated to report the fact > that the VM was shutting down. So, at least from this very simple > test, it would seem that there is no ill effect resulting from > letting virtlogd shut itself down after a timeout. Anything that QEMU would have written to the logfile is lost though. > However, given the concern you've raised, I would personally err on > the side of caution and merge patch 3/8 from this series right away, > so that we are sure 6.2.0 is released in a known-good state. Any > objection to that? Yes, we need to revert that change asap. > > A similar test for virtlockd - it mustn't shutdown while any QEMU guest > > with disks, is running. As mentioned above, I think it is probably fine > > already, but worth checking > > I've never used virtlockd, so I'm not even sure how to make libvirt > take advantage of it. Either way, as of current master the timeout is > not set for virtlockd, so we can take our time figuring this one out. 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 :|
