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

On Sat, Aug 06, 2016 at 03:43:48AM +0000, Eric Wong wrote: > Eric Wong <e at 80x24.org> 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)

I'm one of the developers of Notmuch, an email client that makes extensive use of Xapian. For some time, full multi-version concurrency control (MVCC) has been on our wish list. Olly mentioned that brass now uses free lists---a key step toward full MVCC---and I offered to pitch in on putting the other pieces into place. Before I wade too deep into this, I wanted to propose my plan. Full

I discovered, while trying to set up Tcl bindings for Notmuch (https://notmuchmail.org/), which uses Xapian, that flintlock was not being locked (I had lost updates). I then found that opening a Xapian database for writing directly via the Xapian Tcl bindings also silently fails to lock flintlock. I have taken a copy of flint_lock.cc to play with, and I find that it locks the file when called

On Sun, 21 Feb 2016 22:33:22 +0000, Olly Betts <olly at survex.com> wrote: > On Sun, Feb 21, 2016 at 02:15:25PM +0100, Eric J wrote: > > I discovered, while trying to set up Tcl bindings for Notmuch > > (https://notmuchmail.org/), which uses Xapian, that flintlock was not > > being locked (I had lost updates). > > It seems to work for me, testing with this: >

# HG changeset patch # User Olaf Hering <olaf@aepfle.de> # Date 1350143934 -7200 # Node ID 5aa14d5afe6b1f35b23029ae90b7edb20367bbeb # Parent e0e1350dfe9b7a6cacb1378f75d8e6536d22eb2d hotplug/Linux: close lockfd after lock attempt When a HVM guest is shutdown some of the ''remove'' events can not claim the lock for some reason. Instead they try to grab the lock in a busy

Olly Betts writes: > On Mon, Apr 11, 2016 at 09:54:36AM +0200, Jean-Francois Dockes wrote: > > The question which remains for me is if I should run xapian-compact > > after an initial indexing operation. I guess that this depends on the > > amount of expected updates and that there is no easy answer ? > > I think it's not obvious whether it's a good plan

Hi people I'm running Xapian (1.0.9) and more specifically omega to index a few different databases. After the databases are first indexed (by user A), the dirs get chmod'ed to 0777 to allow user B full access to them. Even after the indexing is done, the file "flintlock" still exists in all database dirs. It's owned by user A (perm: -rw-------). When user B wants

Hi Guys, I'm working on some integration project with Ruby, Rack, Apache, Phusion Passenger and Xapian. I've been having intermittent issues with the flintlock code - it seems that the function FlintLock::lock is never returning and this is locking up the Ruby process. My guess is that Xapian is locking up in a system call and Ruby can't schedule its green threads. I've done

I uninstall xapian1.3 and install xapian-1.2.17 but i still failed hurricanetong at hurricanetong-VirtualBox:~/workspace$ g++ `xapian-config --cxxflags --libs` demo2.cc /tmp/cc2wsfDJ.o: In function `main': demo2.cc:(.text+0x4a): undefined reference to `Xapian::WritableDatabase::WritableDatabase(std::basic_string<char, std::char_traits<char>, std::allocator<char> >

Olly Betts writes: > On Sun, Apr 10, 2016 at 04:47:01PM +0200, Jean-Francois Dockes wrote: > > Some might notice the 50% index size increase. Excessive index size is > > already one relatively rare, but recurring complaint. Except if I did > > something wrong: I'm actually quite surprised by it. > > Did you try compacting the resulting databases? > >

On Fri, Aug 02, 2019 at 02:26:11PM -0500, Eric Blake wrote: > Allow a plugin field to declare whether a parallel plugin can tolerate > windows where fds are not CLOEXEC, or must take precautions to avoid > leaking fds if the plugin may fork. For safety reasons, the flag > defaults to off, but many in-tree plugins can set it to on (most > commonly because they don't fork after

On 7/31/19 4:31 PM, Eric Blake wrote: > The rate filter is potentially opening fds in one thread while another > thread is processing a fork() in the plugin. Although the file is not > open for long, we MUST atomically use CLOEXEC to avoid fd leaks. This > one is a bit harder to observe using only the sh plugin, because the > window is small; you'll have better success at

On platforms that lack atomic CLOEXEC, it's simpler to just always force serialization (no client thread will be executing when nbdkit itself is creating a new file descriptor) than to audit which plugins actually care about not getting any leaked fds. We have one final function that we need to use for atomic CLOEXEC; the next patch will actually put accept4() to use. Maybe this penalization

I recently lost a hard drive and after successfully restoring everything, I think, I'm getting "Error opening database `current.1': DatabaseOpeningError: Couldn't detect type of database" The directory current.1 contains the following files: -rw-rw-r-- 1 jwl jwl  30064640 Aug 28 23:44 docdata.glass -rw-rw-r-- 1 jwl jwl       151 Aug 28 23:44 iamglass -rw-rw-r-- 1 jwl jwl

This is a major rewrite compared to my v1 series, where I've tried a lot harder to ensure that we still accommodate building on Haiku (although I have not actually yet fired up a Haiku VM to try it for myself). I also managed to make the sh plugin fully parallel, on capable platforms. See also my question on patch 10 on whether I've picked the best naming convention. Eric Blake (17):

On 8/1/19 4:12 AM, Richard W.M. Jones wrote: > On Wed, Jul 31, 2019 at 05:01:52PM -0500, Eric Blake wrote: >> On 7/31/19 4:31 PM, Eric Blake wrote: >>> The rate filter is potentially opening fds in one thread while another >>> thread is processing a fork() in the plugin. Although the file is not >>> open for long, we MUST atomically use CLOEXEC to avoid fd

On Wed, 24 Feb 2016 03:17:35 +0000, Olly Betts <olly at survex.com> wrote: >On Mon, Feb 22, 2016 at 12:26:27PM +0100, Eric wrote: >> On Sun, 21 Feb 2016 22:33:22 +0000, Olly Betts <olly at survex.com> wrote: >>> On Sun, Feb 21, 2016 at 02:15:25PM +0100, Eric J wrote: >>>> I discovered, while trying to set up Tcl bindings for Notmuch >>>>

There's enough here to need a review; some of it probably needs backporting to stable-1.12. This probably breaks tests on Haiku or other platforms that have not been as on-the-ball about atomic CLOEXEC; feel free to report issues that arise, and I'll help come up with workarounds (even if we end up leaving a rare fd leak on less-capable systems). Meanwhile, I'm still working on my

I took one of the examples and tried to run against my database ls -l /data1/mail/db/cur.1 total 1129624 -rw-r--r-- 1 jwl jwl 0 2011-06-09 02:27 flintlock -rw-r--r-- 1 jwl jwl 28 2011-06-09 02:27 iamchert -rwxrwxrwx 1 jwl jwl 7258 2011-06-09 02:27 position.baseA -rwxrwxrwx 1 jwl jwl 7046 2011-06-09 02:27 position.baseB -rwxrwxrwx 1 jwl jwl 474226688 2011-06-09 02:28

I ran into an issue when attempting to resume an HVM guest using the libxl_domain_create_restore call. We are using this in the libxl-version of xenopsd, XenServer''s domain manager. The VM''s suspend image is stored on a disk that is mounted in dom0 for the duration of the restore operation, and unmounted afterwards. Xenopsd opens the suspend-image file, and hands the file