Bug 13396 - koha-rebuild-zebra: Couldn't open collection.abs error after 3.18 package update
Summary: koha-rebuild-zebra: Couldn't open collection.abs error after 3.18 package update
Status: RESOLVED DUPLICATE of bug 13404
Alias: None
Product: Koha
Classification: Unclassified
Component: Searching (show other bugs)
Version: 3.22
Hardware: PC Linux
: P5 - low enhancement (vote)
Assignee: Tomás Cohen Arazi
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-12-05 05:51 UTC by Stephen Warren
Modified: 2017-10-20 08:37 UTC (History)
4 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Stephen Warren 2014-12-05 05:51:18 UTC
After the upgrade to 3.18 (auto package update from the repo...), cron spits out errors such as the following every 5 minutes (or perhaps every 5 minutes when there's new data?):

Subject: Cron <root@leibniz> test -x /usr/sbin/koha-rebuild-zebra &&
	koha-rebuild-zebra -q $(koha-list --enabled)

14:10:03-03/12 zebraidx(27193) [warn] Couldn't open collection.abs [No such file or directory]
14:10:03-03/12 zebraidx(27193) [warn] Record didn't contain match fields in (bib1,Local-number)

I can reproduce this by running koha-rebuild-zebra directly:

root@leibniz:/etc/koha# koha-rebuild-zebra -f -v library
...(elided)
........................
Records exported: 553
====================
REINDEXING zebra
====================
22:43:52-04/12 zebraidx(9338) [warn] Couldn't open collection.abs [No such file or directory]
22:43:58-04/12 zebraidx(9338) [warn] Record didn't contain match fields in (bib1,Local-number)
====================
CLEANING
...(continues)

After some Google searching, I wonder if this is because I created /etc/koha/sites/library/koha-conf.xml using a previous version of Koha, and now extra parameters are required? I found some previous discussion of similar problems:

http://irc.koha-community.org/koha/2013-10-14
(search for zebra_bib_index_mode)

... which triggered me to look at the differences between /etc/koha/sites/library/koha-conf.xml and /etc/koha/sites/library/koha-conf.xml. One thing I found was:

+ <zebra_bib_index_mode>__BIBLIOS_INDEXING_MODE__</zebra_bib_index_mode>
+ <zebra_auth_index_mode>__AUTHORITIES_INDEXING_MODE__</zebra_auth_index_mode>
+ <zebra_lockdir>/var/lock/koha/__KOHASITE__</zebra_lockdir>
+ <use_zebra_facets>1</use_zebra_facets>

Do I need to add those to /etc/koha/sites/library/koha-conf.xml? If so, shouldn't the new Koha version add these values automatically, or act as if they were present but set to a value that's compatible with the previous versions' behaviour?
Comment 1 Magnus Enger 2014-12-10 10:07:20 UTC
Hi Stephen! I think this is an example of bug 12584. 

Could you try adding the 4 lines you mention to your koha-conf.xml, restart Zebra and try to do a full reindex?
Comment 2 Stephen Warren 2014-12-14 17:43:32 UTC
Oops. I cut/paste the wrong filename in the bug description re: the Koha config file template. The correct two files I diff'd were:

cd /etc/koha
diff -u sites/library/koha-conf.xml koha-conf-site.xml.in

Anyway, adding those 4 lines to koha-conf.xml does solve this issue.

There are lots of other diffs between the config template and my config file. Should I rebuild the whole config file somehow, or manually apply all the changes?
Comment 3 Magnus Enger 2015-01-12 13:11:49 UTC
I was just having this problem in a GRS1-installation that was upgraded (using the Debian packages) to 3.18.x. These errors were given:

11:12:01-16/12 zebraid10388) [warn] Couldn't open collection.abs [No
such file or directory]
11:21:38-16/12 zebraid10388) [fatal] Out of memory - malloc (305152000
bytes)

and search was not wrking. Adding these lines to koha-conf.xml solved the problem:

 <zebra_bib_index_mode>grs1</zebra_bib_index_mode>
 <zebra_auth_index_mode>grs1</zebra_auth_index_mode>

(The site should still be "upgraded" to DOM indexing, to meet the future removal og GRS1.)
Comment 4 Tomás Cohen Arazi 2015-01-12 14:10:34 UTC
This error is a consecquence of the GRS-1 deprecation, because of which all places where DOM vs. GRS-1 decisions need to be made, DOM is chosen as default.

As this is a configuration error on the user side (and possibly a missing bigger warning on the release notes) I'll close this one as a duplicate of bug 13404, that takes care of telling the user about the mis-configuration and the steps to fix it.

*** This bug has been marked as a duplicate of bug 13404 ***
Comment 5 Stephen Warren 2015-01-13 04:52:46 UTC
Do you have a link to the instructions how to change from GRS1 to DOM?

Note that mentioning this in the release notes doesn't feel like a good solution to the problem; my site was upgraded automatically through the Debian packages. If version upgrades are expected to cause this kind of incompatibility, the Debian repo should not automatically upgrade people to a new major release. Rather, once a particular major package version is installed, the install should stick at the same major version (with minor/patch updates) rather than moving to the new version. The sysadmin should be able to switch versions by explicitly choosing the new version. IIRC, Debian itself already has quite a few packages that work this way that could be used as examples.
Comment 6 Tomás Cohen Arazi 2015-01-26 19:06:23 UTC
(In reply to Stephen Warren from comment #5)
> Do you have a link to the instructions how to change from GRS1 to DOM?
> 
> Note that mentioning this in the release notes doesn't feel like a good
> solution to the problem; my site was upgraded automatically through the
> Debian packages. If version upgrades are expected to cause this kind of
> incompatibility, the Debian repo should not automatically upgrade people to
> a new major release. Rather, once a particular major package version is
> installed, the install should stick at the same major version (with
> minor/patch updates) rather than moving to the new version. The sysadmin
> should be able to switch versions by explicitly choosing the new version.
> IIRC, Debian itself already has quite a few packages that work this way that
> could be used as examples.

Stephen, we made a check on About Koha > System information so we can point you there in this situation.

I share the concern about the "automatic upgrade" but didn't find a way to convince people to implement it in a different way, I ain't no Debian packaging guru, otherwise I would have fixed it myself.
Comment 7 Jatinder Kumar Samyal 2016-05-24 11:15:49 UTC
I have just upgraded koha 3.12 to 3.22 and facing problem in searching stuff in OPAC as well as staff interface.

I just gone through various replies of the forum for same kind of problem and found some changes to be done in koha-conf.xml file. But i am not getting out of problem.

Kindly share complete koha-conf.xml file, if available.

rgds.

JK Samyal
Comment 8 Pablo AB 2017-10-20 08:37:43 UTC
Take a look to this instructions: 

https://wiki.koha-community.org/wiki/Switching_to_dom_indexing