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?
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?
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?
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.)
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 ***
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.
(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.
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
Take a look to this instructions: https://wiki.koha-community.org/wiki/Switching_to_dom_indexing