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

[Andrea Bolognani]

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