Re: [libvirt] [PATCH] Firewall : let libvirtd proceed after verifying locking args

I recently encountered a situation where an unclean ebtables shutdown caused /var/lib/ebtables/lock to be left behind. When libvirtd was started on such a system, it caused libvirtd to "hang". Reason:

While probing to check if locking was supported, libvirt runs this command synchronously : # /usr/sbin/ebtables --concurrent -L And this seemed to go on with msgs like : Trying to obtain lock /var/lib/ebtables/lock Trying to obtain lock /var/lib/ebtables/lock Trying to obtain lock /var/lib/ebtables/lock Result: Libvirtd never recovered from this scenario, and the system was essentially unable to start any VMs. The following patch fixes this scenario: ----------------------------------------------------------- >From ec245eccc03e8a69dc2c2e6edbf30a7b34eb74d0 Mon Sep 17 00:00:00 2001 From: Prerna Saxena <prerna(a)linux.vnet.ibm.com&gt; Date: Fri, 26 Dec 2014 15:24:45 -0500 Subject: [PATCH] Firewall : let libvirtd proceed after verifying valid locking args. Commit dc33e6e4a5a5d42 introduces locking args to be run with [eb/ip]tables to determine whether locking is supported. However, this command needs to be run asynchronously ( as against its present synchronous run), and needs to be gracefully terminated once the job is done. Else it can potentially stall libvirtd with messages like : "Trying to acquire lock ..."