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
Records exported: 553
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)
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:
(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:
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:
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
and search was not wrking. Adding these lines to koha-conf.xml solved the problem:
(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.
Take a look to this instructions: