summaryrefslogtreecommitdiffstats
path: root/bitbake/lib/bb/utils.py
diff options
context:
space:
mode:
authorYu Ke <ke.yu@intel.com>2010-12-29 15:28:48 +0800
committerRichard Purdie <rpurdie@linux.intel.com>2010-12-30 09:28:45 +0000
commit6ee0c26e21f48dcd47af88ed5c174e76e76a3e42 (patch)
tree11b741182e8a2e2cb5a105dd74c9de15f07cf3ff /bitbake/lib/bb/utils.py
parent93043c55dd3ea0005801bd692f9ec31d86f5aec5 (diff)
downloadpoky-6ee0c26e21f48dcd47af88ed5c174e76e76a3e42.tar.gz
bb.utils: check if lock file is writable, to fix bug 606
Bug 606 report that if $DL_DIR is read-only, do_fetch will simply hang without any error message. The root cause is that: bb.fetch.go()->bb.utils.lockfile() will try to lock file ${DL_DIR}/xxxxx.lock. Since ${DL_DIR} is read-only, it will cause IOError exception. Although lockfile() can catch the exception, currently code simply ignore all the exception and continue the loop. it make sense if the exception is caused by locking contention, but in the read-only $DL_DIR case, it cause endless waiting unfortunately. So this patch add read-only check for lockfile to avoid the silent hang. Fix [BUGID #606] Signed-off-by: Yu Ke <ke.yu@intel.com>
Diffstat (limited to 'bitbake/lib/bb/utils.py')
-rw-r--r--bitbake/lib/bb/utils.py4
1 files changed, 4 insertions, 0 deletions
diff --git a/bitbake/lib/bb/utils.py b/bitbake/lib/bb/utils.py
index f468fafc12..e02969c07f 100644
--- a/bitbake/lib/bb/utils.py
+++ b/bitbake/lib/bb/utils.py
@@ -401,6 +401,10 @@ def lockfile(name):
401 bb.msg.error(bb.msg.domain.Util, "Error, lockfile path does not exist!: %s" % path) 401 bb.msg.error(bb.msg.domain.Util, "Error, lockfile path does not exist!: %s" % path)
402 sys.exit(1) 402 sys.exit(1)
403 403
404 if not os.access(path, os.W_OK):
405 bb.msg.error(bb.msg.domain.Util, "Error, lockfile path is not writable!: %s" % path)
406 sys.exit(1)
407
404 while True: 408 while True:
405 # If we leave the lockfiles lying around there is no problem 409 # If we leave the lockfiles lying around there is no problem
406 # but we should clean up after ourselves. This gives potential 410 # but we should clean up after ourselves. This gives potential