Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Raphael Hertzog <hertzog <at> debian.org>
Subject: Bug#642608: /usr/bin/dpkg-gencontrol: Race condition with tempfile for parallel builds
Newsgroups: gmane.linux.debian.devel.dpkg.bugs
Date: Tuesday 11th October 2011 06:34:48 UTC (over 5 years ago)
On Mon, 10 Oct 2011, Guillem Jover wrote:
> The correct solution would be to lock a file we know must be there, so
> that there's no race condition and no possible cruft leftover. For
> example debian/control or debian/changelog (or the file arguments
> specified on the command line).

What do you mean with "file arguments"? if you mean "debian/files" then
it won't work as that file is replaced with rename() so we're back to the
initial situation where you can have a lock on the now deleted/replaced
file.

Using debian/control would work but it doesn't seem very clean.

> Also we should be using fcntl(2) instead of flock(2) to get NFS support,
> but this seems tricky on perl?

Not really, it's a built-in function on systems that support it. The
question is whether we have to care about systems that do not support it.

Perl's flock() is the recommended interface because it will use whatever
is supported among flock(), fnctl() and lockf() so it's more
portable.


I have another idea to propose. Create "debian/files.new" with
O_CREAT|O_EXCL and if it fails with EEXIST, sleep for Xms and try again.
It's not optimal in the sense that we're not going to sleep
exactly the required amount of time, but at least it doesn't involve
messing with unrelated files.

A third solution would be to use semaphores...

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/go/ulule-rh/
 
CD: 9ms