Hi All, I am another person with a problem when upgrading Koha that items disappear from search. I have read faithfully the news groups and have tried the suggestions found there concerning zebra indexing and search using marc21 with no success. I am upgrading from 3.08.01.002 to 3.10.06 on Debian Squeeze obsessively following the instructions in the INSTALL.debian section for the upgrade. I have detailed notes of what I have done and found but in a nutshell. 1) Download and extract koha-3.10.06.tar.gz 2) Check and install cpan dependencies 3) Make the upgrade a. perl Makefile.PL --prev-install-log /usr/share/koha/misc/koha-install-log b. make c. make test d. sudo make upgrade 4) verified the environment variables 5) updated the database from the web admin client. At this point I can go into either the OPAC or ADMIN client and successfully search. BUT once I execute any rebuild_zebra.pl command (all finish without any errors) upon searching the search results show the number of items returned but each item shows "Availability: No copies available". I have used many permutations of the rebuild_zebra.pl command. The one that seems to be recommended most is " /usr/share/koha/bin/migration_tools/rebuild_zebra.pl -v -r -a -b -x ". If I edit an existing marc record I can see that volume until I run the rebuild_zebra.pl command again. I have been returning to this problem on an off for the better part of a year. I have gone to the extent of verifying any number of problems raised in the koha lists (such as making sure that there are no duplicate Field 001 values in the db) and would appreciate any help. Thanks -- Dave ---------------------------------------------------------------------------- --- David L. Whelchel 725 SE Derby Street Pullman, WA 99163 whelchel@pullman.com http://www.dlwa.com
At 05:43 PM 5/29/2013 -0700, David Whelchel wrote: [snip]
At this point I can go into either the OPAC or ADMIN client and successfully search. BUT once I execute any rebuild_zebra.pl command (all finish without any errors) upon searching the search results show the number of items returned but each item shows "Availability: No copies available". I have used many permutations of the rebuild_zebra.pl command. The one that seems to be recommended most is " /usr/share/koha/bin/migration_tools/rebuild_zebra.pl -v -r -a -b -x ". If I edit an existing marc record I can see that volume until I run the rebuild_zebra.pl command again. I have been returning to this problem on an off for the better part of a year. I have gone to the extent of verifying any number of problems raised in the koha lists (such as making sure that there are no duplicate Field 001 values in the db) and would appreciate any help.
A couple of thoughts (off-the-wall, and certainly may not reflect the general usage of Koha, only some in-house "experiences" over the last couple of years.) "Items available" depends on a numerous data points (damaged status, not for loan, use restrictions at least.) Is the search that is "failing" along the lines of 'opac-search.pl?idx=kw&q=lubbock&limit=available' -- note the '&limit=available'? One of my "to do" jobs is to remove the "Availability // limit to currently available items" option from the OPAC page as we are a reference, not lending, library and clicking on "Availability" systematically brings items down to "No results found!" (See e.g. <http://opac.navalmarinearchive.com/cgi-bin/koha/opac-search.pl?q=lubbock>.) I also remember at some point that we had problems using the -a and -x together for rebuild_zebra.pl (but can't remember why or find any notes.) We now "rebuild" in two stages: first 'rebuild_zebra.pl -b -r -v -x', then 'rebuild_zebra.pl -a -r -v' Best - Paul
Just to say, it may not be the Koha upgrade that caused the problem. We haven't upgraded our Koha system lately (we're running 3.10.02) but the server that it runs on recently had a system upgrade. We thought Koha came through without any problems (search and display seemed fine), but newly catalogued records are not being returned in searches. I ran a report to look for items catalogued since the upgrade, and they are indeed there, so it's another indexing problem. The indexing process seems to be a weak spot in Koha. In our case, it's usually the first (and only) thing to fail whenever anything is changed. Mind you, you should have seen the rest of the Society's web site after the upgrade. . .it took two IT wizards several hours to get it back on its feet. By comparison Koha seems fairly robust. Elaine On Thu, May 30, 2013 at 2:13 PM, Paul <paul.a@aandc.org> wrote:
At 05:43 PM 5/29/2013 -0700, David Whelchel wrote: [snip]
At this point I can go into either the OPAC or ADMIN client and
successfully search. BUT once I execute any rebuild_zebra.pl command (all finish without any errors) upon searching the search results show the number of items returned but each item shows "Availability: No copies available". I have used many permutations of the rebuild_zebra.pl command. The one that seems to be recommended most is " /usr/share/koha/bin/migration_**tools/rebuild_zebra.pl -v -r -a -b -x ". If I edit an existing marc record I can see that volume until I run the rebuild_zebra.pl command again. I have been returning to this problem on an off for the better part of a year. I have gone to the extent of verifying any number of problems raised in the koha lists (such as making sure that there are no duplicate Field 001 values in the db) and would appreciate any help.
A couple of thoughts (off-the-wall, and certainly may not reflect the general usage of Koha, only some in-house "experiences" over the last couple of years.)
"Items available" depends on a numerous data points (damaged status, not for loan, use restrictions at least.) Is the search that is "failing" along the lines of 'opac-search.pl?idx=kw&q=**lubbock&limit=available<http://opac-search.pl?idx=kw&q=lubbock&limit=available>' -- note the '&limit=available'? One of my "to do" jobs is to remove the "Availability // limit to currently available items" option from the OPAC page as we are a reference, not lending, library and clicking on "Availability" systematically brings items down to "No results found!" (See e.g. <http://opac.**navalmarinearchive.com/cgi-** bin/koha/opac-search.pl?q=**lubbock<http://opac.navalmarinearchive.com/cgi-bin/koha/opac-search.pl?q=lubbock>
.)
I also remember at some point that we had problems using the -a and -x together for rebuild_zebra.pl (but can't remember why or find any notes.) We now "rebuild" in two stages: first 'rebuild_zebra.pl -b -r -v -x', then 'rebuild_zebra.pl -a -r -v'
Best - Paul ______________________________**_________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/**mailman/listinfo/koha<http://lists.katipo.co.nz/mailman/listinfo/koha>
-- Elaine Bradtke Data Wrangler VWML English Folk Dance and Song Society | http://www.efdss.org Cecil Sharp House, 2 Regent's Park Road, London NW1 7AY Tel +44 (0) 20 7485 2206 (This number is for the English Folk Dance and Song Society in London, England. If you wish to phone me personally, send an e-mail first. I work off site) -------------------------------------------------------------------------- Registered Company No. 297142 Charity Registered in England and Wales No. 305999 --------------------------------------------------------------------------- "Writing about music is like dancing about architecture" --Elvis Costello (Musician magazine No. 60 (October 1983), p. 52)
Hello everybody, I have three systems running Koha, two test systems and a production system I'm currently building. I built them all from Koha Live DVD, then applied all the updates/upgrades available so they're running on Xubuntu/Ubuntu 12.04 LTS, I believe. Two of the systems are running Koha 3.12, the third is running 3.10.5. The problem I'm having is slow checkout times. On the 3.12 production system, I scan a barcode and the system takes thirty seconds to respond. The server shows circulation.pl taking up 100% of the CPU, and that's two 3GHz Xeon processors. The 3.10.5 system takes three seconds at the most, and it's running on an old PC. I'm having the same slow response times running offline checkout--on 3.12, it takes thirty seconds per item; on 3.10.5, it takes a couple of minutes to run through 500+ items. The other 3.12 system, running on a PC identical to the 3.10.5 system, has response times similar to the production system. I found a few potential solutions in the list archives, and none of them worked. I'm not running the zebra daemon in the background, and I'm not logging changes to bibliographic or item records. Is anyone else having this problem? Any suggestions for fixing it? (I'm switching my sysadmin hat for a librarian hat for the rest of the day, so I may not be able to get back to anyone for a while.) Thanks, Fred King Medical Librarian, MedStar Washington Hospital Center fred.king@medstar.net 202-877-6221 CONFIDENTIAL: The information contained in this communication, including its attachments, may contain confidential information and is intended only for the individual(s) or entity(ies) to whom it is addressed. The information contained in this communication may also be protected by legal privilege, federal law or other applicable law. If you are not the intended recipient of this communication, you are hereby notified that any distribution, dissemination or duplication of this communication is strictly prohibited. If you have received this communication in error, please immediately delete and destroy all copies of this message and please immediately notify us of the error by separate communication. Thank you.
Hi, On Thu, May 30, 2013 at 11:09 AM, King, Fred <Fred.King@medstar.net> wrote:
The problem I'm having is slow checkout times. On the 3.12 production system, I scan a barcode and the system takes thirty seconds to respond. The server shows circulation.pl taking up 100% of the CPU, and that's two 3GHz Xeon processors.
I'd be curious to know what an strace attached to one of those circulation.pl processes shows. Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org
Galen suggested I upload the output to paste.koha-community.org. If I got it right, all 500+ lines are at http://paste.koha-community.org/30 That's as much as I could capture; circulation.pl got a new PID each time, and it took me a few seconds to type it in. --Fred Fred King Medical Librarian, MedStar Washington Hospital Center fred.king@medstar.net 202-877-6221 -----Original Message----- From: Galen Charlton [mailto:gmc@esilibrary.com] Sent: Thursday, May 30, 2013 2:29 PM To: King, Fred Cc: koha@lists.katipo.co.nz Subject: Re: [Koha] Slow checkout times in 3.12 Hi, On Thu, May 30, 2013 at 11:09 AM, King, Fred <Fred.King@medstar.net> wrote:
The problem I'm having is slow checkout times. On the 3.12 production system, I scan a barcode and the system takes thirty seconds to respond. The server shows circulation.pl taking up 100% of the CPU, and that's two 3GHz Xeon processors.
I'd be curious to know what an strace attached to one of those circulation.pl processes shows. Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org CONFIDENTIAL: The information contained in this communication, including its attachments, may contain confidential information and is intended only for the individual(s) or entity(ies) to whom it is addressed. The information contained in this communication may also be protected by legal privilege, federal law or other applicable law. If you are not the intended recipient of this communication, you are hereby notified that any distribution, dissemination or duplication of this communication is strictly prohibited. If you have received this communication in error, please immediately delete and destroy all copies of this message and please immediately notify us of the error by separate communication. Thank you.
On 31 May 2013 07:28, King, Fred <Fred.King@medstar.net> wrote:
Galen suggested I upload the output to paste.koha-community.org. If I got it right, all 500+ lines are at http://paste.koha-community.org/30
That's as much as I could capture; circulation.pl got a new PID each time, and it took me a few seconds to type it in.
--Fred
Hi All Sadly (and also gladly) I can't replicate this http://demo-intra.mykoha.co.nz is running stock Koha 3.12.0 with the package from the repository, on Debian Squeeze. Circ takes around a second. Its on a box with lower specs than yours Fred, so the 2 differences are Ubuntu and the LiveDVD. You could try a circ yourself. (user staff pass staff1) For a borrower cardnumber 23529000058017 and for a barcode testcard should work. Chris
Hi, On Thu, May 30, 2013 at 11:09 AM, King, Fred <Fred.King@medstar.net> wrote:
The problem I'm having is slow checkout times. On the 3.12 production system, I scan a barcode and the system takes thirty seconds to respond. The server shows circulation.pl taking up 100% of the CPU, and that's two 3GHz Xeon processors. The 3.10.5 system takes three seconds at the most, and it's running on an old PC. I'm having the same slow response times running offline checkout--on 3.12, it takes thirty seconds per item; on 3.10.5, it takes a couple of minutes to run through 500+ items. The other 3.12 system, running on a PC identical to the 3.10.5 system, has response times similar to the production system.
Is it *only* checkout operations that are slow? I.e., are all other operations like catalog search, patron search, and the like running at comparable speeds between your 3.10 and 3.12 systems? Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org
*Only* checkouts. Everything else is running just fine. I think I broke something when I upgraded from 3.10.5 to 3.12. I'm going to try a fresh install and see what happens. Fred King Medical Librarian, MedStar Washington Hospital Center fred.king@medstar.net 202-877-6221 -----Original Message----- From: Galen Charlton [mailto:gmc@esilibrary.com] Sent: Thursday, May 30, 2013 4:09 PM To: King, Fred Cc: koha@lists.katipo.co.nz Subject: Re: [Koha] Slow checkout times in 3.12 Hi, On Thu, May 30, 2013 at 11:09 AM, King, Fred <Fred.King@medstar.net> wrote:
The problem I'm having is slow checkout times. On the 3.12 production system, I scan a barcode and the system takes thirty seconds to respond. The server shows circulation.pl taking up 100% of the CPU, and that's two 3GHz Xeon processors. The 3.10.5 system takes three seconds at the most, and it's running on an old PC. I'm having the same slow response times running offline checkout--on 3.12, it takes thirty seconds per item; on 3.10.5, it takes a couple of minutes to run through 500+ items. The other 3.12 system, running on a PC identical to the 3.10.5 system, has response times similar to the production system.
Is it *only* checkout operations that are slow? I.e., are all other operations like catalog search, patron search, and the like running at comparable speeds between your 3.10 and 3.12 systems? Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org CONFIDENTIAL: The information contained in this communication, including its attachments, may contain confidential information and is intended only for the individual(s) or entity(ies) to whom it is addressed. The information contained in this communication may also be protected by legal privilege, federal law or other applicable law. If you are not the intended recipient of this communication, you are hereby notified that any distribution, dissemination or duplication of this communication is strictly prohibited. If you have received this communication in error, please immediately delete and destroy all copies of this message and please immediately notify us of the error by separate communication. Thank you.
Elaine Bradtke schreef op do 30-05-2013 om 16:59 [+0100]:
The indexing process seems to be a weak spot in Koha.
When we set up nagios monitoring for Koha instances, one of the things we include is checking that there is nothing in the zebra queue more than about an hour old. This ensures that the zebra reindexing is happening. One of these days I should look into adding something that queries zebra directly and checking that the indexed count lines up with the count in Koha. -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5957 6D23 8B16 EFAB FEF8 7175 14D3 6485 A99C EB6D
Le 31/05/2013 00:51, Robin Sheat a écrit :
Elaine Bradtke schreef op do 30-05-2013 om 16:59 [+0100]:
The indexing process seems to be a weak spot in Koha.
When we set up nagios monitoring for Koha instances, one of the things we include is checking that there is nothing in the zebra queue more than about an hour old. This ensures that the zebra reindexing is happening. Could you share the script you've made to check that ? We're also using nagios to monitor, and that would be useful.
thx -- Paul POULAIN - Associé-gérant Tel : (33) 4 91 81 35 08 http://www.biblibre.com Logiciels Libres pour les bibliothèques et les centres de documentation
We'de also be interesting in that zebra monitoring script... I imagine many of the community are using Nagios for monitoring and this isn't something I'de got round to implementing myself (and sharing) yet either. Cheers On 31 May 2013 12:56, Paul Poulain <paul.poulain@biblibre.com> wrote:
Le 31/05/2013 00:51, Robin Sheat a écrit :
Elaine Bradtke schreef op do 30-05-2013 om 16:59 [+0100]:
The indexing process seems to be a weak spot in Koha.
When we set up nagios monitoring for Koha instances, one of the things we include is checking that there is nothing in the zebra queue more than about an hour old. This ensures that the zebra reindexing is happening. Could you share the script you've made to check that ? We're also using nagios to monitor, and that would be useful.
thx
-- Paul POULAIN - Associé-gérant Tel : (33) 4 91 81 35 08 http://www.biblibre.com Logiciels Libres pour les bibliothèques et les centres de documentation _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
-- Martin Renvoize Software Engineer, PTFS Europe Ltd Content Management and Library Solutions Skype: Landline: 0203 286 8685 Mobile: 07725985636 http://www.ptfs-europe.com
Paul Poulain schreef op vr 31-05-2013 om 13:56 [+0200]:
Could you share the script you've made to check that ? We're also using nagios to monitor, and that would be useful.
Of course. They're pretty straight forward. You can find our nagios stuff in the catalyst Koha git repo, in the 'nagios' branch. Or you can browse them here: http://git.catalyst.net.nz/gw?p=koha.git;a=tree;f=nagios;h=d69b65e3cb957f4ef... -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5957 6D23 8B16 EFAB FEF8 7175 14D3 6485 A99C EB6D
Dear Paul, Recently I installed koha 3.12 on Debian Squeeze, I had problems with opac not showing results.(No results found) I even posted the error log here, and was waiting for reply from many days. Thank you so much for your reply, I tried the steps mentioned by you, and now am successful for showing the results in OPAC. before the problem got fixed, I was using -b -r -v and got the message REINDEXING zebra saying, 13:22:44-01/06 zebraidx(13633) [warn] No such record type: grs.marcxml.record I do not understand, why do I get this message ? Thank you Satish On Thu, May 30, 2013 at 6:43 PM, Paul <paul.a@aandc.org> wrote:
At 05:43 PM 5/29/2013 -0700, David Whelchel wrote: [snip]
At this point I can go into either the OPAC or ADMIN client and
successfully search. BUT once I execute any rebuild_zebra.pl command (all finish without any errors) upon searching the search results show the number of items returned but each item shows "Availability: No copies available". I have used many permutations of the rebuild_zebra.pl command. The one that seems to be recommended most is " /usr/share/koha/bin/migration_**tools/rebuild_zebra.pl -v -r -a -b -x ". If I edit an existing marc record I can see that volume until I run the rebuild_zebra.pl command again. I have been returning to this problem on an off for the better part of a year. I have gone to the extent of verifying any number of problems raised in the koha lists (such as making sure that there are no duplicate Field 001 values in the db) and would appreciate any help.
A couple of thoughts (off-the-wall, and certainly may not reflect the general usage of Koha, only some in-house "experiences" over the last couple of years.)
"Items available" depends on a numerous data points (damaged status, not for loan, use restrictions at least.) Is the search that is "failing" along the lines of 'opac-search.pl?idx=kw&q=**lubbock&limit=available<http://opac-search.pl?idx=kw&q=lubbock&limit=available>' -- note the '&limit=available'? One of my "to do" jobs is to remove the "Availability // limit to currently available items" option from the OPAC page as we are a reference, not lending, library and clicking on "Availability" systematically brings items down to "No results found!" (See e.g. <http://opac.**navalmarinearchive.com/cgi-** bin/koha/opac-search.pl?q=**lubbock<http://opac.navalmarinearchive.com/cgi-bin/koha/opac-search.pl?q=lubbock>
.)
I also remember at some point that we had problems using the -a and -x together for rebuild_zebra.pl (but can't remember why or find any notes.) We now "rebuild" in two stages: first 'rebuild_zebra.pl -b -r -v -x', then 'rebuild_zebra.pl -a -r -v'
Best - Paul ______________________________**_________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/**mailman/listinfo/koha<http://lists.katipo.co.nz/mailman/listinfo/koha>
--
participants (10)
-
Chris Cormack -
David Whelchel -
Elaine Bradtke -
Galen Charlton -
King, Fred -
Martin Renvoize -
Paul -
Paul Poulain -
Robin Sheat -
satish