aboutsummaryrefslogtreecommitdiffstats
path: root/main/abuild/0001-abuild-workaround-with-fetch-lock-file-on-nfs.patch
blob: 83a79f09b6eb6c0e678bcd2e89decf5952c32f5f (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
From 8468825035d1c0af12abbb67aea85260cd048946 Mon Sep 17 00:00:00 2001
From: Natanael Copa <ncopa@alpinelinux.org>
Date: Wed, 26 Aug 2015 08:14:36 +0200
Subject: [PATCH] abuild: workaround with fetch lock file on nfs

flock(2) on an NFS mount will on the server side convert the lock to a
POSIX lock (fcntl(F_SETLK)). This means that abuild running on NFS
server and client will create different locks and they will both try
download same file at same time.

The proper fix would be to patch curl to have an option to create a
posix lock for the downlaoded file or create a flock -c like wrapper
that creates posix lock.

Meanwhile, we implement a stupid test for existance of the lockfile
before we go on. This is not race-safe because other process could
create the lockfile after the [ -e $lockfile ] test and before the file
is created.

At least it is not worse that no locking at all.
---
 abuild.in | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/abuild.in b/abuild.in
index b8d8851..f01fe2b 100644
--- a/abuild.in
+++ b/abuild.in
@@ -342,6 +342,15 @@ uri_fetch() {
 	mkdir -p "$SRCDEST"
 
 	CLEANUP_FILES="$CLEANUP_FILES $lockfile"
+
+	# best-effort workaround for NFS which has issues with flock
+	if [ -e "$lockfile" ]; then
+		msg "Waiting for ${lockfile##*/}..."
+		while [ -e "$lockfile" ]; do
+			sleep 0.5s
+		done
+	fi
+
 	(
 	flock -n -x 9 || msg "Waiting for ${lockfile##*/}..."
 	flock -x 9
-- 
2.5.0