On Thu, Apr 02, 2020 at 14:51:13 +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. The log entry about VM shutdown is added by libvirt and not by qemu. In fact there's no way for qemu to "socket activate" anything since we are logging the stderr/out of qemu via vitlogd via a pipe. If vitlogd exits while a VM is running you lose stdout/stderr logging of the qemu process and that is _very_ bad.
