aboutsummaryrefslogtreecommitdiffstats
path: root/tools/hotplug
diff options
context:
space:
mode:
authorOlaf Hering <olaf@aepfle.de>2012-10-18 09:35:01 +0100
committerOlaf Hering <olaf@aepfle.de>2012-10-18 09:35:01 +0100
commit5622adc37204b9408d0ee1de57ad16236052f2fd (patch)
tree66fa5c5a27ef4352e1c4df03e997417426b1da7b /tools/hotplug
parent301febc0fe0fe873b2cdac419eb4053b6c5e6019 (diff)
downloadxen-5622adc37204b9408d0ee1de57ad16236052f2fd.tar.gz
xen-5622adc37204b9408d0ee1de57ad16236052f2fd.tar.bz2
xen-5622adc37204b9408d0ee1de57ad16236052f2fd.zip
hotplug/Linux: close lockfd after lock attempt
When a HVM guest is shutdown some of the 'remove' events can not claim the lock for some reason. Instead they try to grab the lock in a busy loop, until udev reaps the xen-hotplug-cleanup helper. After analyzing the resulting logfile its not obvious what the cause is. The only explanation is that bash (?) gets confused if the same lockfd is opened again and again. Closing it in each iteration seem to fix the issue. This was observed with sles11sp2 (bash 3.2) and 4.2 xend. Signed-off-by: Olaf Hering <olaf@aepfle.de> Acked-by: Ian Campbell <Ian.campbell@citrix.com> [ ijc -- added the comment ] Committed-by: Ian Campbell <ian.campbell@citrix.com>
Diffstat (limited to 'tools/hotplug')
-rw-r--r--tools/hotplug/Linux/locking.sh3
1 files changed, 3 insertions, 0 deletions
diff --git a/tools/hotplug/Linux/locking.sh b/tools/hotplug/Linux/locking.sh
index 0e2a531cb3..e34f155438 100644
--- a/tools/hotplug/Linux/locking.sh
+++ b/tools/hotplug/Linux/locking.sh
@@ -59,6 +59,9 @@ claim_lock()
print "y\n" if $fd_inum eq $file_inum;
' "$_lockfile" )
if [ x$rightfile = xy ]; then break; fi
+ # Some versions of bash appear to be buggy if the same
+ # $_lockfile is opened repeatedly. Close the current fd here.
+ eval "exec $_lockfd<&-"
done
}