Reindex Queue not Updating, xapian php binding issues

Log errors indicated that the db was not openable for writing.

I don't understand this bug report. I've clicked the "Add all nodes to queue" button on the Xapian settings page, and run cron.php and the # of items in the reindex queue updated appropriately. Are you referring to something else? What are the steps to duplicate this?

if the database is not writable,
watchdog will show entries with "Could not get writable database."
As a result, the number in "There are X items waiting to be indexed." won't decrease.

I've got the same problem, too.
Is it because of not having libxapian15? My repos only give me libxapian13 and no libsearch-xapian-perl neither. It's a Debian GNU/Linux 4.0

The module created /files/xapian successfully, and there are files in the directory.

Any help appreciated.

Yes, that is true -- if Xapian is unable to lock the database so that it can write to it, then content can not be indexed and the number of items rightly will not decrease. This is a symptom of a bigger problem, and it would be great to track down just what is causing this for you.

Has it managed to index any content for you? Did it work for a while and then stop, or did it never work?

Can you delete all the entire xapian directory within files/ and click the re-index button. What happens?

As to whether or not this is due to your version of libxapian, unfortunately I do not know. I only know that libzapian15 works fine on my system, and that I've never tried libxapian13. Is an upgrade possible for you?

I'm getting the same error - cron.php either spins wheels for a while then tries to download, or stops with a fatal error saying the database isn't writable. (files directory path is correct and writable by my webserver).

This is using libxapian15 on debian etch.

I added extension:xapian.so to php.ini, but that doesn't seem to have done much. Also did sudo ln -s /usr/share/php5/xapian.php /usr/share/php/xapian.php
to no effect either.

Getting this error when I try to search (and sometimes on cron: Fatal error: Class 'XapianDatabase' not found in /sites/all/modules/xapian/xapian.module on line 340)

And this in watchdog:

include_once() [function.include]: Failed opening 'xapian.php' for inclusion (include_path='.:/usr/share/php:/usr/share/pear') in /sites/all/modules/xapian/xapian.module on line 13.

@catch: I believe your problem is different. You have not properly installed the Xapian bindings. Are they in /usr/share/php5? If so, add that path to php.ini and restart Apache -- does the error go away? If not, be sure that the include_path changed in the error message. If not, you probably modified the wrong php.ini file. To find the correct php.ini file, review the output of phpinfo(). (In theory the symbolic link you added should fix this too, but that's an ugly solution -- updating include_path is the proper solution, and a change for which we can see the result by following the directions I've provided.)

"Has it managed to index any content for you?"
- no. The number of the queue stays the same after each cron-run.

"Did it work for a while and then stop, or did it never work?"
- it did never work. it's a fresh install

"Can you delete all the entire xapian directory within files/ and click the re-index button. What happens?"
- i'll test that.

"Is an upgrade possible for you?"
- I did an apt-get update and apt-get upgrade before installing xapian. Had a short look at packages.debian.org. libxapian15 is in testing, libxapian13 is in stable

on ubuntu libxapian13 is provided until feisty (704)

I'll delete all xapian stuff from /files today evening and report back.

@maulwuff: let us know how it goes. Also, when you look at Drupal's status report (Administer >> Logs >> Status Report), what does it report for Xapian bindings?

@maulwuff: Can you also check your error_log? And configure php.ini to enable all errors and warnings, seeing if anything more shows up on your screen or in your watchdog log. We need to understand why Xapian is failing to acquire a lock on your index files.

Jeremy - that's the issue. I'm not getting xapian.php built at all with the packages (either etch or etch-backports).

Edit - looks like a bug fixed here: http://trac.xapian.org/changeset/8736

@Xapian bindings: 0.9.9

@watchdog:
i got 2 pages full of warnings:
1st message type is:
DatabaseLockError: Unable to acquire database write lock files/xapian_database/db_lock

2nd message type is:
Could not get writable database.

after deleting the content from files/xapian_database, next try:
no new files were created after saving xapian settings
they were created somewhere while cron runs, but right the first run gave me this:
Fatal error: Call to undefined function new_TermGenerator() in /var/www/sites/all/modules/xapian/xapian.php on line 1425

@catch:
the xapian.php is in the php5-xapian package, and will be installed to /usr/share/php5/xapian.php (ubuntu gutsy)

Wow, those are old bindings (released 2006-11-09).

This module has only been tested with version 1.0.5 and 1.0.6 as far as I know. I'm highly suspicious that you're below the minimum requirements, though I don't know what the minimum requirements actually are. I'm tempted to change the module to depend on version 1.0.5 of the bindings or better.

Can you manually compile a more modern version of the bindings and see if that actually fixes your problem?

@maulwuff - nope, not for me on debian etch.

I'll try it on gutsy later tonight and see if I can get a decent copy of the bindings manually.

I grabbed a xapian.php from a snapshot tarball ( http://oligarchy.co.uk/xapian/trunk/) , and got the same error as maulwuff - new_TermGenerator()

@Jeremy:
yes I'll try.

@catch:
jop. I first tested local on gutsy, put the xapian.php in the module folder, because I am lazy, and uploaded it to the server where it simply worked *g*

there is no xapian.php on etch:
http://packages.debian.org/etch/i386/php5-xapian/filelist

Now, I deleted mine and tried to include the xapian.so, but that does not do anything good. (no hint on xapian with phpinfo(); )

various versions of xapian.php can be found here: http://oligarchy.co.uk/xapian/1.0.6/

For some reason admin/logs is reporting 0.9.9 still. And I'm now just getting this error:

DatabaseLockError: Unable to acquire database write lock files/xapian_database/db_lock

Stuck it straight in the modules folder to see what happened and deleted files/xapian_database, now getting this:

Call to undefined function TermGenerator_set_stemmer()

Sometimes cron completes successfully, but no luck with indexing.

Please installing the Xapian bindings as is described here: http://xapian.org/download.php

@Jeremy:
on gutsy, it says: Xapian bindings 1.0.2
and the queue reduces its number.
so 1.0.5 is not the bottom :P

@etch:
I followed the instructions on
http://xapian.org/download.php
and now I have bindings 1.05

I had to add a link for xapian.php:

mkdir /usr/share/php
ln -s /usr/share/php5/xapian.php /usr/share/php/xapian.php

I have NOT modified my php.ini.

wohoo, the queue does count down.

My conclusion: at leas bindings 1.0.2 are necessary

That sounds good to me, I patched the 5.x development tree. The Drupal status report will now report an error if you try to use bindings older than version 1.0.2.

Marking as fixed, re-open if necessary.

I just got it working too after following http://xapian.org/download.php - this should go into README.txt to avoid duplicate issues so reopening for that. I'll roll a patch over the next day or so if no-one beats me to it.

Please open a new issue for that. The whole thread has nothing in common with documentation. It's not good to transform issues to fit multiple problems.
We have describd here, what to do, to get indexing working. If people are in search for this problem, they won't find it, if the issues title deals with documentation problems.
This issue is fixed and done in my eyes. rest in peace ;)

maulwuff, the README.txt included with this module tells users to use apt-get to install xapian from the debian repositories wthout mentioning version requirements. Since those packages are incompatible with the module, that was the cause of this bug. So updating it will avoid other people having the same bug again - that way, they might not even need to search for this issue, given it'll be documented rather than hidden in an issue queue.

Either way, patch here: http://drupal.org/node/274689