On Fri, Jul 27, 2012 at 08:39:42AM +0200, Bastian Blank wrote: > On Thu, Jul 26, 2012 at 02:48:51PM -0700, Ben Pfaff wrote: > > open() with O_CREAT|O_EXCL yields EEXIST if the file being opened is a > > symlink. lockfile_try_lock() interpreted that error code to mean that > > some other process had created the lock file in the meantime, so it went > > around its loop again, which found out the same thing, which led to a hang. > > > > This commit fixes the problem by dropping O_EXCL. I don't see any reason > > that it's actually necessary. That means that the loop itself is > > unnecessary, so this commit drops that too. > > I would always use the lock file at the target location of the database > and not follow symlinks there. Otherwise more than one lock file can > exist.
We have to follow symlinks, so that the lock file ends up in /var/lib, because FHS says that /etc is static, and therefore may be mounted read-only, and therefore we cannot create a read/write file there. > On second thought, drop the lock file and use fcntl(db, F_SETLK…) on the > database file itself. This lock is automatically released if the process > dies. We cannot drop the lock file, because the lock file grants the right not merely to modify the database but to put another file in its place. That is, the locked entity is the name, not the inode to which the name refers. The lock file itself is already locked with fcntl(), and always has been from the earlier version of the database. To obtain a write lock with fcntl(), one must have the file open for writing, and therefore the lock file cannot be in /etc. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
