[libvirt PATCH 4/8] logging, locking: Set default timeout of 120 seconds

[Daniel P. Berrangé]

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 :|