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. 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? > 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. -- Andrea Bolognani / Red Hat / Virtualization
