Re: debian (1.2.22-3~bpo8+1) package build failure

Eric Wong <[email protected]> wrote:
> I'm trying to test a trivial patch to set FD_CLOEXEC on the
> flintlock lockfd when using F_OFD_SETLK

Fwiw, this is the patch I was originally going to test.
(but now I see maybe my F_SETFD might only need to be
 called on F_OFD_SETLK success)   Description at bottom.

--- a/backends/flint_lock.cc
+++ b/backends/flint_lock.cc
@@ -108,6 +108,10 @@ FlintLock::lock(bool exclusive, string & explanation) {
 	return ((errno == EMFILE || errno == ENFILE) ? FDLIMIT : UNKNOWN);
     }
 
+#ifdef FD_CLOEXEC
+    (void)fcntl(lockfd, F_SETFD, FD_CLOEXEC);
+#endif
+
 #ifdef F_OFD_SETLK
     // F_OFD_SETLK has exactly the semantics we want, so use it if it's
     // available.  Support was added in Linux 3.15, and there's work on

---
The problem I'm attempting to solve comes from wanting doing an
inplace full reindex of a giant git mail repo[1] while not
stalling small incremental updates which happen as mail flows
in.

So in the reindexer, I start "git log" once for the entire
history (which feeds data for git cat-file --batch, which feeds
Xapian); and commit+close the Xapian::WritableDatabase every 100
entries.  This allows more time-critical processes doing
incremental updates to have a chance to index its data sooner
rather than waiting 20-30 minutes for the full reindex to finish.

The "git log" process is started once, after opening the Xapian
DB (I need to open the Xapian DB to get the last-indexed-commit
from metadata); but it seems the lack of close-on-exec for
the flintlock FD with F_OFD_* usage causes the lock to remain
held after closing the Xapian DB...


[1] this is an archive of the git mailing list since 2005:
    https://public-inbox.org/git/[email protected]/T/