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: > > On Wed, Apr 01, 2020 at 08:53:41PM +0200, Andrea Bolognani wrote: > > > [Service] > > > EnvironmentFile=-@sysconfdir@/sysconfig/virtlogd > > > -ExecStart=@sbindir@/virtlogd $VIRTLOGD_ARGS > > > +ExecStart=@sbindir@/virtlogd --timeout 120 $VIRTLOGD_ARGS > > > ExecReload=/bin/kill -USR1 $MAINPID > > > # Loosing the logs is a really bad thing that will > > > # cause the machine to be fenced (rebooted), so make > > > > I'm fairly sure this is not safe on its own. > > > > 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. 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 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 :|
