coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: coreutils-8.13.29-43a9 on Linux/PowerPC


From: Jim Meyering
Subject: Re: coreutils-8.13.29-43a9 on Linux/PowerPC
Date: Sat, 08 Oct 2011 19:58:37 +0200

Bruno Haible wrote:
> On Linux/PowerPC in 64-bit mode:
>
> FAIL: tail-2/F-vs-missing (exit: 1)
> ===================================
...
> + rm -rf
> /home/haible/multibuild-1313/linuxppc64/coreutils-8.13.29-43a9/tests/gt-F-vs-missing.Jxgm
> rm: cannot remove
> /home/haible/multibuild-1313/linuxppc64/coreutils-8.13.29-43a9/tests/gt-F-vs-missing.Jxgm/missing':
> Directory not empty
> + test 0 = 0
> + __st=1
> + exit 1
>
> This happens on an NFS mounted volume. The failure is reproducible with
> probability 80%.
> Less than 1 second after the test failed, the directory _is_ empty and
> can be removed. It looks like a race condition within "rm -rf" to me:
> After removing 'missing/file', you need to wait a bit until you can remove
> 'missing'.

Thanks for the report.
Does this fix it?

>From bb1c6912f23edcd77ccb18043b2b83db8754f8d9 Mon Sep 17 00:00:00 2001
From: Jim Meyering <address@hidden>
Date: Sat, 8 Oct 2011 19:57:21 +0200
Subject: [PATCH] tests: avoid tail-2/F-vs-missing failure on NFS

* tests/tail-2/F-vs-missing: This test would fail about 80% of the
time on linux/powerpc when run in an NFS-mounted directory.
Reported by Bruno Haible in
http://thread.gmane.org/gmane.comp.gnu.coreutils.general/1726/focus=1727
---
 tests/tail-2/F-vs-missing |   15 +++++++++++++++
 1 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/tests/tail-2/F-vs-missing b/tests/tail-2/F-vs-missing
index 35b103b..d46a624 100755
--- a/tests/tail-2/F-vs-missing
+++ b/tests/tail-2/F-vs-missing
@@ -46,4 +46,19 @@ tail_re='has appeared' retry_delay_ check_tail_output .1 7 ||

 kill -HUP $pid

+cleanup()
+{
+  local delay="$1"
+  rm -rf missing ||
+    { sleep $delay; return 1; }
+}
+
+# Try repeatedly to remove the temporary directory.
+# This is normally unnecessary, because the containing directory will
+# be removed by code from init.sh.  However, when this particular test
+# is run on an NFS-mounted volume, sometimes init.sh's cleanup code
+# fails because the directory is not yet really empty, perhaps because
+# the tail process (reading missing/file) is not yet killed.
+retry_delay_ cleanup .1 6
+
 Exit $fail
--
1.7.7.rc0.362.g5a14



reply via email to

[Prev in Thread] Current Thread [Next in Thread]