[Koha] View SQL generated by Average Loan Time report?
Hi all, Is there a way to view the query that the Average Loan Time report is using (issues_avg_stats.pl)? I'd like to put it in a SQL report and add further limits to it, it would be handy to be able to dump the query to the screen or log it somewhere. Thanks! Cindy --- Cindy Murdock Ames IT Services Director Meadville Public Library | CCFLS https://meadvillelibrary.org | https://ccfls.org ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha
Re: [Koha] Performance improvement suggestions
Hi Kevin, By any chance are you using certbot to provide https encryption? I recently set up a new server using certbot, and Koha was incredibly slow until I realized that the line in the ssl.conf file generated by certbot in /etc/apache2/sites-available had the Include lines for plack in the intranet and opac sections commented out. So in my case plack was running but it wasn't doing anything. Not sure how that happened, but once I uncommented them and restarted apache Koha got much faster. I manually set up certbot rather than using the option in koha-create, if that makes any difference. c. --- Cindy Murdock Ames IT Services Director Meadville Public Library | CCFLS https://meadvillelibrary.org | https://ccfls.org Please report tech support issues in Mantis: https://mantis.ccfls.org On Thu, Aug 31, 2023 at 2:11 PM Fridolin SOMERS < fridolin.som...@biblibre.com> wrote: > Please answer to the mailling list instead of me directly. > > Le 31/08/2023 à 03:11, Furst, Kevin a écrit : > > 1. Plack is enabled and running > > 2. Haven't run db tuner you suggested yet. Will look at it today. > > 3. Hardware is Intel Xeon E5520 8GB RAM and (8) 2TB SSDs in a RAID. > > > > > > *Kevin Furst* > > Technology Director > > Pine River-Backus Schools > > o | 218.587.8030 > > @ | kfu...@prbschools.org <mailto:kfu...@prbschools.org> > > > > Technology Office/Help Desk: 218-587-8510 > > > > /Confidentiality Notice: This E-mail message, including any attachments, > > is for the sole use of the intended recipient(s) and may contain > > confidential and privileged information. Any unauthorized review, use, > > disclosure or distribution is prohibited. If you are not the intended > > recipient, please contact the sender by reply E-mail and destroy all > > copies of the original message./ > > > > > > On Wed, Aug 30, 2023 at 8:19 PM Fridolin SOMERS > > mailto:fridolin.som...@biblibre.com>> > wrote: > > > > Hi, > > > > Did you tune DB server ? Like with mysqltuner.pl < > http://mysqltuner.pl> > > > > Did you enable Plack mode ? > > https://wiki.koha-community.org/wiki/Koha_on_Debian#Setup_plack > > <https://wiki.koha-community.org/wiki/Koha_on_Debian#Setup_plack> > > > > Please give more informations on hardware. > > > > Best regards, > > > > Le 30/08/2023 à 09:54, Furst, Kevin a écrit : > > > Hi, > > > > > > I'm running v.23.05.x on Ubuntu 20.04. I've currently got zebra > > running for > > > the search engine. It works correctly but is really slow. We're > > talking ~10 > > > seconds for a return on catalog search query and maybe 5-6 > > seconds on a > > > patron search in the staff side. Our library only has ~1000 > > patrons and 20k > > > titles. > > > > > > I'm wondering if anyone has any performance enhancement > > recommendations on > > > the server-side that they've had success with that would help > > speed up > > > those times. > > > > > > *Kevin Furst* > > > Technology Director > > > Pine River-Backus Schools > > > o | 218.587.8030 > > > @ | kfu...@prbschools.org <mailto:kfu...@prbschools.org> > > > > > > Technology Office/Help Desk: 218-587-8510 > > > > > > *Confidentiality Notice: This E-mail message, including any > > attachments, is > > > for the sole use of the intended recipient(s) and may contain > > confidential > > > and privileged information. Any unauthorized review, use, > > disclosure or > > > distribution is prohibited. If you are not the intended > > recipient, please > > > contact the sender by reply E-mail and destroy all copies of the > > original > > > message.* > > > ___ > > > > > > Koha mailing list http://koha-community.org > > <http://koha-community.org> > > > Koha@lists.katipo.co.nz <mailto:Koha@lists.katipo.co.nz> > > > Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha > > <https://lists.katipo.co.nz/mailman/listinfo/koha> > > > > -- > > Fridolin SOMERS > <mailto:fridolin.som...@biblibre.com>> > > Software and system maintainer 濾 > > BibLi
Re: [Koha] Background job / Staging MARC import stuck at 0%
Hi Anna, Are you able to check your server for zombie processes? (Hint: run "ps aux |grep Z" from the command line or else run "top" and look at the end of the Tasks line for the number of zombies.) Since upgrading to 22.11 from 22.05 I've had an issue where the background_jobs_worker.pl tasks would turn into zombie processes. If all the background job worker tasks become zombies then imports won't get processed and it remains stuck at the "import queued" stage. I've been unable to identify the cause or a proper fix, but for the time being I've made a hacky cron script that runs every minute checking for these zombies and killing their parent process, which seems to restart the queue, but you have to retry the upload (the original job remains in the queue with a progress of "null"). Sorry I don't have a proper solution, I was just curious if others were seeing this symptom. Cindy ------- Cindy Murdock Ames IT Services Director Meadville Public Library | CCFLS https://meadvillelibrary.org | https://ccfls.org On Mon, May 29, 2023 at 11:06 PM Anna Shields wrote: > Michael, > > Did you ever have any luck resolving this? > > I'm having a similar issue in which my imports get stuck at 0% on the > staging step. I, too, seem to have a functioning RabbitMQ, and none of the > suggestions I saw in this thread seemed to make a difference. > > I'm now on v22.11.06-3, and updating hasn't seemed to make any difference, > either. > > Anna > > On Tue, May 16, 2023 at 7:01 PM wrote: > > > Hi Michael, > > > > Did you also restart some services after changing the script including > > memcache? > > > > Sometimes it is necessary but not remember for this case. > > > > You should also look > > https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33412 > > > > Mengü Yazıcıoğlu > > Devinim Yazılım Eğitim Danışmanlık > > Reşit Galip Cad. No: 29/6 > > Çankaya/ANKARA > > > > Tel: (312) 446 86 68 > > Cep: (532) 701 90 27 > > > > On 13.05.2023 16:21, Michael Brown wrote: > > > I tried Mengü's suggestion of editing manage-marc-import.pl, to no > > avail. > > > Still hangs at enqueuement; no messages, no errors, simply hangs and > > spins > > > my CPU into a frenzy. Responses to George's message below: > > > > > > On Wed, May 10, 2023 at 8:34 AM George Veranis > > wrote: > > > > > >> Hi Michael, > > >> > > >> Could you check the following things: > > >> > > >> 1) if your rabbitmq-server is running ? > > >> > > > Yes. > > > > > > > > >> 1.1) if yes, then check if the cluster of nodes in rabbit exist , the > > >> command is: > > >> rabbitmqctl cluster_status > > >> > > > Cluster status of node rabbit@kiko ... > > > Basics > > > > > > Cluster name: rabbit@kiko > > > > > > Disk Nodes > > > rabbit@kiko > > > > > > Running Nodes > > > rabbit@kiko > > > > > > Versions > > > rabbit@kiko: RabbitMQ 3.9.21 on Erlang 24.3.4.2 > > > > > > Maintenance status > > > > > > Node: rabbit@kiko, status: not under maintenance > > > > > > Alarms > > > > > > (none) > > > > > > Network Partitions > > > > > > (none) > > > > > > Listeners > > > > > > Node: rabbit@kiko, interface: [::], port: 61613, protocol: stomp, > > purpose: > > > STOMP > > > Node: rabbit@kiko, interface: [::], port: 25672, protocol: clustering, > > > purpose: inter-node and CLI tool communication > > > Node: rabbit@kiko, interface: [::], port: 5672, protocol: amqp, > purpose: > > > AMQP 0-9-1 and AMQP 1.0 > > > > > > Feature flags > > > > > > Flag: implicit_default_bindings, state: enabled > > > Flag: maintenance_mode_status, state: enabled > > > Flag: quorum_queue, state: enabled > > > Flag: stream_queue, state: enabled > > > Flag: user_limits, state: enabled > > > Flag: virtual_host_metadata, state: enabled > > > > > > > > > > > >> 1.1.1) if not shows you something in json format you can try to start > it > > >> with command > > >> rabbitmqctl start_app > > >> > > >> N/A, rabbitmq is already running. > > > > > >> 1.2 ) If no , start it and check the logs from your rabbitmq-server at > > >> /var/log/r
Re: [Koha] Background job / Staging MARC import stuck at 0%
Hi Michael,
Can you confirm your koha-conf.xml contains a message broker section, like
this?
localhost
61613
guest
guest
I had the same problem after upgrading from 22.05 to 22.11; I'm guessing
22.05 must have had some defaults set in the code that allowed the message
broker to start automatically without this section whereas 22.11 must not.
I was missing this section and added it and was able to complete imports
after restarting Koha.
I'm still having the issue with zombie background jobs (I'm afraid to test
rolling back the code on a production server) but I made a hacky bash
script to run as a cron job to check for them and kill them off so at least
our staff can do batch imports without issue, but that's another matter.
HTH!
Cindy
---
Cindy Murdock Ames
IT Services Director
Meadville Public Library | CCFLS
https://meadvillelibrary.org | https://ccfls.org
Please report tech support issues in Mantis: https://mantis.ccfls.org
On Thu, Mar 2, 2023 at 8:51 AM Michael Brown wrote:
> Greetings:
>
> My name is Michael Brown and I am a professional cataloger and SirsiDynix
> System Admin at the Texas State Library & Archives in Austin (20+ years
> now). I have been using Koha on Arch Linux in my home library for about a
> year now. I am migrating my home server to AlmaLinux and I'm having a
> problem.
>
> I am running Koha 22.11.03.000 Rosalie on AlmaLinux 9.1. Staging a MARC
> file for import gets stuck at 0%. On screen, I am able to select the file
> for import (bib.mrc), review the profile options (but I don't change any
> defaults), and then click on "Stage for import" at the bottom. Next screen
> reads:
>
> The job has been enqueued! It will be processed as soon as possible.
> 0%
> View detail of the enqueued job
>
> After a few seconds, it changes to (and then hangs at):
>
> The job has been enqueued! It will be processed as soon as possible.
> 0% Not started
> View detail of the enqueued job
>
> Clicking on "View detail of the enqueued job" I see:
>
> Details of job #22
>
> Job ID: 22
> Status:New
> Progress:0 / 0
> Type:Staged MARC records for import
> Queued:03/02/2023 05:42
> Started:
> Ended:
>
> Report
> Detailed messages
> Return to the job list
>
> The corresponding entry in mariadb is:
>
> id 22
> status new
> progress NULL
> size 0
> borrowernumber 1
> type stage_marc_for_import
> queue Name of the queue the job is sent to long_tasks
> data {"encoding":"UTF-8","comments":"","basket_id":null...
> context JSON-serialized context information for the job
> {"flags":1,"branch":"ALMA","interface":"intranet",...
> enqueued_on 2023-03-02 05:42:33
> started_on NULL
> ended_on NULL
>
> (If you need to see the full entries for "data" and "context", please let
> me know.)
>
> tmp, koha_upload, and lock directories have been tweaked and fine tuned. I
> was getting early warnings about them not being set in koha-conf.xml so I
> created them (and set correct permissions) and I can see the uploaded file
> (for job 22 the name is 2287629673fb980ad4102f62ebeaa1b9_bib.mrc), so the
> actual upload function appears to be working.
>
> I am getting no apache errors and no other on-screen diagnostics.
>
> I have Koha 22.05.02.000 running on Arch Linux that imports this file just
> fine. Similarly, I have Koha latest running on a Debian VM that can import
> this file just fine, too.
>
> What am I missing?
>
> Details of my system:
>
> Koha version: 22.11.03.000 Rosalie
> OS version ('uname -a'): Linux alma 5.14.0-162.12.1.el9_1.x86_64 #1 SMP
> PREEMPT_DYNAMIC Mon Jan 23 14:51:52 EST 2023 x86_64
> Perl interpreter: /usr/bin/perl
> Perl version: 5.032001
> Perl @INC: /usr/share/koha/lib
> /usr/local/lib64/perl5/5.32
> /usr/local/share/perl5/5.32
> /usr/lib64/perl5/vendor_perl
> /usr/share/perl5/vendor_perl
> /usr/lib64/perl5
> /usr/share/perl5
> /var/lib/koha/plugins
> MySQL version: mysql Ver 15.1 Distrib 10.5.16-MariaDB, for Linux (x86_64)
> using EditLine wrapper
> Apache version: Server version: Apache/2.4.53 (AlmaLinux) Server built: Jul
> 20 2022 00:00:00
> Memcached: Servers: 127.0.0.1:11211 | Namespace: KOHA | Status: running. |
> Config read from: koha-conf.xml
> Zebra version: Zebra 2.2.7 (C) 1994-2023, Index Data Zebra is free
> software, covered by the GNU General Public License, and you are welcome to
> change it and/or distribute copies of it under certain conditions. SHA1 ID:
> a
Re: [Koha] Help needed with zombie background_jobs processes
That's an interesting thought. I *am* missing the section in my config file, but am I interpreting the patch correctly that it defaults to "1" if it's not present? ------- Cindy Murdock Ames IT Services Director Meadville Public Library | CCFLS https://meadvillelibrary.org | https://ccfls.org Please report tech support issues in Mantis: https://mantis.ccfls.org On Wed, Apr 19, 2023 at 12:24 PM Jonathan Druart < jonathan.dru...@bugs.koha-community.org> wrote: > It would be interesting to revert the changes from 32558 that have > been backported into 22.11.04 and see if it helps. > > Le mer. 19 avr. 2023 à 18:01, Cindy Murdock Ames a > écrit : > > > > Hi Jonathan, > > > > I just tried sending SHGCHLD to the parent processes, it didn't have any > effect. The parents are "/usr/bin/perl /usr/share/koha/bin/ > background_jobs_worker.pl --queue default" and "/usr/bin/perl > /usr/share/koha/bin/background_jobs_worker.pl --queue long_tasks". > > > > worker-error.log has a few entries like these three from today: > > 20230419 08:44:53 ccfls-koha-worker-long_tasks: client (pid 12169) > killed by signal 13, respawning > > 20230419 09:36:06 ccfls-koha-worker: client (pid 14398) killed by signal > 13, respawning > > 20230419 09:59:35 ccfls-koha-worker: client (pid 29935) killed by signal > 13, respawning > > > > Those timestamps correspond to three jobs in the jobs queue that didn't > complete and have a "null/n" (n being numbers that I think correspond to > the number of things in the batch). The first is a batch item record > modification and the other two are holds queue updates. > > > > I cancelled these three jobs and the zombies remained. > > > > worker-output.log has a number of entries like these, but unfortunately > there are no timestamps so I can't link it to anything, although the > timestamp on the file itself is from yesterday at 13:08, which I think > corresponded to a successful staging and import of records. > > > > Use of uninitialized value $subfield_value in pattern match (m//) at > /usr/share/koha/lib/Koha/SimpleMARC.pm line 435. > > Use of uninitialized value $subfield_value in string eq at > /usr/share/koha/lib/Koha/SimpleMARC.pm line 435. > > > > I did try something else. The parent process for the long queue had > apparently already respawned, but the one for the default one hadn't, so I > killed it with -9. The two zombies that had been there went away and the > default queue restarted. Before I did that I tried a MARC upload, it was > stuck at 0%. I cancelled the job and retried it after killing the default > queue and it worked, but it spawned a new zombie which was a child of the > long_tasks queue. Yesterday it seemed to work if there was only one > zombie, but not two. No new entries in either of the worker- files. > > > > Thanks for your help. > > > > c. > > --- > > Cindy Murdock Ames > > IT Services Director > > Meadville Public Library | CCFLS > > https://meadvillelibrary.org | https://ccfls.org > > > > Please report tech support issues in Mantis: https://mantis.ccfls.org > > > > > > On Wed, Apr 19, 2023 at 2:44 AM Jonathan Druart < > jonathan.dru...@bugs.koha-community.org> wrote: > >> > >> Did you have a look at worker-*.log? Nothing useful there? > >> > >> You can try to send SIGCHLD to the parent to kill the zombie. > >> > >> Le mar. 18 avr. 2023 à 22:09, Cindy Murdock Ames > a écrit : > >> > > >> > A few other things I've noticed: > >> > > >> > - Sometimes the zombie processes will go away on their own, sometimes > it seems when you retry the MARC import or whatever it was that failed. > This one is really weird to me as in all my years as a sysadmin I thought > it was not possible for zombie processes to go away without a reboot. But > maybe that's changed and now zombies can rise from the dead. Lol. > >> > > >> > - In looking at the jobs list in Koha, it seems that Holds queue > updates are especially prone to getting stuck at a progress of null/1. > >> > > >> > - If you reattempt a job that is stuck (ie, reattempting a MARC file > upload or what not) it will often succeed. The original failed job remains > with a progress of null. > >> > > >> > c. > >> > --- > >> > Cindy Murdock Ames > >> > IT Services Direc
Re: [Koha] Help needed with zombie background_jobs processes
Hi Jonathan, I just tried sending SHGCHLD to the parent processes, it didn't have any effect. The parents are "/usr/bin/perl /usr/share/koha/bin/ background_jobs_worker.pl --queue default" and "/usr/bin/perl /usr/share/koha/bin/background_jobs_worker.pl --queue long_tasks". worker-error.log has a few entries like these three from today: 20230419 08:44:53 ccfls-koha-worker-long_tasks: client (pid 12169) killed by signal 13, respawning 20230419 09:36:06 ccfls-koha-worker: client (pid 14398) killed by signal 13, respawning 20230419 09:59:35 ccfls-koha-worker: client (pid 29935) killed by signal 13, respawning Those timestamps correspond to three jobs in the jobs queue that didn't complete and have a "null/n" (n being numbers that I think correspond to the number of things in the batch). The first is a batch item record modification and the other two are holds queue updates. I cancelled these three jobs and the zombies remained. worker-output.log has a number of entries like these, but unfortunately there are no timestamps so I can't link it to anything, although the timestamp on the file itself is from yesterday at 13:08, which I think corresponded to a successful staging and import of records. Use of uninitialized value $subfield_value in pattern match (m//) at /usr/share/koha/lib/Koha/SimpleMARC.pm line 435. Use of uninitialized value $subfield_value in string eq at /usr/share/koha/lib/Koha/SimpleMARC.pm line 435. I did try something else. The parent process for the long queue had apparently already respawned, but the one for the default one hadn't, so I killed it with -9. The two zombies that had been there went away and the default queue restarted. Before I did that I tried a MARC upload, it was stuck at 0%. I cancelled the job and retried it after killing the default queue and it worked, but it spawned a new zombie which was a child of the long_tasks queue. Yesterday it seemed to work if there was only one zombie, but not two. No new entries in either of the worker- files. Thanks for your help. c. ----------- Cindy Murdock Ames IT Services Director Meadville Public Library | CCFLS https://meadvillelibrary.org | https://ccfls.org Please report tech support issues in Mantis: https://mantis.ccfls.org On Wed, Apr 19, 2023 at 2:44 AM Jonathan Druart < jonathan.dru...@bugs.koha-community.org> wrote: > Did you have a look at worker-*.log? Nothing useful there? > > You can try to send SIGCHLD to the parent to kill the zombie. > > Le mar. 18 avr. 2023 à 22:09, Cindy Murdock Ames a > écrit : > > > > A few other things I've noticed: > > > > - Sometimes the zombie processes will go away on their own, sometimes it > seems when you retry the MARC import or whatever it was that failed. This > one is really weird to me as in all my years as a sysadmin I thought it was > not possible for zombie processes to go away without a reboot. But maybe > that's changed and now zombies can rise from the dead. Lol. > > > > - In looking at the jobs list in Koha, it seems that Holds queue updates > are especially prone to getting stuck at a progress of null/1. > > > > - If you reattempt a job that is stuck (ie, reattempting a MARC file > upload or what not) it will often succeed. The original failed job remains > with a progress of null. > > > > c. > > --- > > Cindy Murdock Ames > > IT Services Director > > Meadville Public Library | CCFLS > > https://meadvillelibrary.org | https://ccfls.org > > > > Please report tech support issues in Mantis: https://mantis.ccfls.org > > > > > > On Tue, Apr 18, 2023 at 3:55 PM Cindy Murdock Ames > wrote: > >> > >> Yes, it's 22.11.04, package version. > >> > >> --- > >> Cindy Murdock Ames > >> IT Services Director > >> Meadville Public Library | CCFLS > >> https://meadvillelibrary.org | https://ccfls.org > >> > >> > >> > >> > >> On Tue, Apr 18, 2023 at 2:59 PM Jonathan Druart < > jonathan.dru...@bugs.koha-community.org> wrote: > >>> > >>> Hi Cindy, > >>> Which exact version of Koha 22.11.xx? It should be the latest one. > >>> Regards, > >>> Jonathan > >>> > >>> Le mar. 18 avr. 2023 à 19:13, Cindy Murdock Ames > a écrit : > >>> > > >>> > Hi all, > >>> > > >>> > A couple weekends ago I upgraded our Koha instance from 22.05 to > 22.11, and > >>> > I'm having trouble with the background_jobs processes becoming > zombies > >>&g
Re: [Koha] Help needed with zombie background_jobs processes
A few other things I've noticed: - Sometimes the zombie processes will go away on their own, sometimes it seems when you retry the MARC import or whatever it was that failed. This one is really weird to me as in all my years as a sysadmin I thought it was not possible for zombie processes to go away without a reboot. But maybe that's changed and now zombies can rise from the dead. Lol. - In looking at the jobs list in Koha, it seems that Holds queue updates are especially prone to getting stuck at a progress of null/1. - If you reattempt a job that is stuck (ie, reattempting a MARC file upload or what not) it will often succeed. The original failed job remains with a progress of null. c. --- Cindy Murdock Ames IT Services Director Meadville Public Library | CCFLS https://meadvillelibrary.org | https://ccfls.org Please report tech support issues in Mantis: https://mantis.ccfls.org On Tue, Apr 18, 2023 at 3:55 PM Cindy Murdock Ames wrote: > Yes, it's 22.11.04, package version. > > --- > Cindy Murdock Ames > IT Services Director > Meadville Public Library | CCFLS > https://meadvillelibrary.org | https://ccfls.org > > > > > On Tue, Apr 18, 2023 at 2:59 PM Jonathan Druart < > jonathan.dru...@bugs.koha-community.org> wrote: > >> Hi Cindy, >> Which exact version of Koha 22.11.xx? It should be the latest one. >> Regards, >> Jonathan >> >> Le mar. 18 avr. 2023 à 19:13, Cindy Murdock Ames a >> écrit : >> > >> > Hi all, >> > >> > A couple weekends ago I upgraded our Koha instance from 22.05 to 22.11, >> and >> > I'm having trouble with the background_jobs processes becoming zombies >> > after a very short amount of time, necessitating a reboot. I suspect >> it's >> > a misconfiguration on my part, so if someone can shed some light I'd >> really >> > appreciate it! >> > >> > The first symptom was our MARC imports getting stuck at "import queued", >> > and after some digging (and thanks to the thread in this list with the >> > subject of "Background job / Staging MARC import stuck at 0%" I found I >> was >> > entirely missing the section in our config, so I added >> > this: >> > >> > >> >localhost >> >61613 >> >guest >> >guest >> > >> > >> > >> > Which seemed to resolve it, but now I find that the background_jobs >> > processes are going zombie after processing only a few jobs. Here's >> some >> > info from the rabbitmq log after restarting the server: >> > >> > =INFO REPORT 18-Apr-2023::12:23:46 === >> > node : rabbit@ccflskoha >> > home dir : /var/lib/rabbitmq >> > config file(s) : /etc/rabbitmq/rabbitmq.config (not found) >> > cookie hash: ojvkUE6eUtku7kHlx3uiFg== >> > log: /var/log/rabbitmq/rab...@ccflskoha.log >> > sasl log : /var/log/rabbitmq/rab...@ccflskoha-sasl.log >> > database dir : /var/lib/rabbitmq/mnesia/rabbit@ccflskoha >> > >> > Is it problematic that /etc/rabbitmq/rabbitmq.config is missing? >> Anything >> > else I should be looking at? We're running on Ubuntu SE 18.04 if that >> is >> > helpful. >> > >> > Thanks much! >> > Cindy >> > >> > >> > --- >> > Cindy Murdock Ames >> > IT Services Director >> > Meadville Public Library | CCFLS >> > https://meadvillelibrary.org | https://ccfls.org >> > ___ >> > >> > Koha mailing list http://koha-community.org >> > Koha@lists.katipo.co.nz >> > Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha >> > ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha
Re: [Koha] Help needed with zombie background_jobs processes
Yes, it's 22.11.04, package version. --- Cindy Murdock Ames IT Services Director Meadville Public Library | CCFLS https://meadvillelibrary.org | https://ccfls.org On Tue, Apr 18, 2023 at 2:59 PM Jonathan Druart < jonathan.dru...@bugs.koha-community.org> wrote: > Hi Cindy, > Which exact version of Koha 22.11.xx? It should be the latest one. > Regards, > Jonathan > > Le mar. 18 avr. 2023 à 19:13, Cindy Murdock Ames a > écrit : > > > > Hi all, > > > > A couple weekends ago I upgraded our Koha instance from 22.05 to 22.11, > and > > I'm having trouble with the background_jobs processes becoming zombies > > after a very short amount of time, necessitating a reboot. I suspect > it's > > a misconfiguration on my part, so if someone can shed some light I'd > really > > appreciate it! > > > > The first symptom was our MARC imports getting stuck at "import queued", > > and after some digging (and thanks to the thread in this list with the > > subject of "Background job / Staging MARC import stuck at 0%" I found I > was > > entirely missing the section in our config, so I added > > this: > > > > > >localhost > >61613 > >guest > >guest > > > > > > > > Which seemed to resolve it, but now I find that the background_jobs > > processes are going zombie after processing only a few jobs. Here's some > > info from the rabbitmq log after restarting the server: > > > > =INFO REPORT 18-Apr-2023::12:23:46 === > > node : rabbit@ccflskoha > > home dir : /var/lib/rabbitmq > > config file(s) : /etc/rabbitmq/rabbitmq.config (not found) > > cookie hash: ojvkUE6eUtku7kHlx3uiFg== > > log: /var/log/rabbitmq/rab...@ccflskoha.log > > sasl log : /var/log/rabbitmq/rab...@ccflskoha-sasl.log > > database dir : /var/lib/rabbitmq/mnesia/rabbit@ccflskoha > > > > Is it problematic that /etc/rabbitmq/rabbitmq.config is missing? > Anything > > else I should be looking at? We're running on Ubuntu SE 18.04 if that is > > helpful. > > > > Thanks much! > > Cindy > > > > > > --- > > Cindy Murdock Ames > > IT Services Director > > Meadville Public Library | CCFLS > > https://meadvillelibrary.org | https://ccfls.org > > ___ > > > > Koha mailing list http://koha-community.org > > Koha@lists.katipo.co.nz > > Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha > ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha
[Koha] Help needed with zombie background_jobs processes
Hi all, A couple weekends ago I upgraded our Koha instance from 22.05 to 22.11, and I'm having trouble with the background_jobs processes becoming zombies after a very short amount of time, necessitating a reboot. I suspect it's a misconfiguration on my part, so if someone can shed some light I'd really appreciate it! The first symptom was our MARC imports getting stuck at "import queued", and after some digging (and thanks to the thread in this list with the subject of "Background job / Staging MARC import stuck at 0%" I found I was entirely missing the section in our config, so I added this: localhost 61613 guest guest Which seemed to resolve it, but now I find that the background_jobs processes are going zombie after processing only a few jobs. Here's some info from the rabbitmq log after restarting the server: =INFO REPORT 18-Apr-2023::12:23:46 === node : rabbit@ccflskoha home dir : /var/lib/rabbitmq config file(s) : /etc/rabbitmq/rabbitmq.config (not found) cookie hash: ojvkUE6eUtku7kHlx3uiFg== log: /var/log/rabbitmq/rab...@ccflskoha.log sasl log : /var/log/rabbitmq/rab...@ccflskoha-sasl.log database dir : /var/lib/rabbitmq/mnesia/rabbit@ccflskoha Is it problematic that /etc/rabbitmq/rabbitmq.config is missing? Anything else I should be looking at? We're running on Ubuntu SE 18.04 if that is helpful. Thanks much! Cindy ------- Cindy Murdock Ames IT Services Director Meadville Public Library | CCFLS https://meadvillelibrary.org | https://ccfls.org ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha
Re: [Koha] Publication date (yyyy-yyyy) advanced search option not working in my Koha instance
Hi Katrin, Thanks for the response. To answer your questions: -- Are you using Zebra or Elasticsearch? Zebra, version 2.0.59 -- Is 008 pos. 7-10 cataloged correctly for the records in question? I think so? Here's a couple samples: @ 110102s2020 nyua 000 0 eng d @ 180420s2019 nyua j 000 1 eng d -- Can you share how the search link looks like that does work vs. the one that doesn't? If I do a "yr,st-year" search via keyword search (which works): https://circ.ccfls.org/cgi-bin/koha/catalogue/search.pl?advsearch=1=kw=yr%2Cst-year%3A2019-2020_by=relevance If I search from the "Publication date (-)" search: https://circ.ccfls.org/cgi-bin/koha/catalogue/search.pl?advsearch=1=yr%2Cst-year=2019-2020_by=relevance From Bywater's Koha demo using Publication date (-): https://intranet.bywatersolutions.com/cgi-bin/koha/catalogue/search.pl?advsearch=1=yr%2Cst-year=2011-2012=and=kw=and=kw_by=relevance (I used a different date range because there was only one result for 2019-2020 in the demo system.) Thanks much, Cindy ------- Cindy Murdock Ames IT Services Director Meadville Public Library | CCFLS https://meadvillelibrary.org | https://ccfls.org ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha
[Koha] Publication date (yyyy-yyyy) advanced search option not working in my Koha instance
Hi all,
We recently upgraded to 20.05.08 from 19.11, and we've found that the
advanced search option in the staff interface for publication date by year
range isn't producing any results for us if we use it. Specifying it with
y,st-year in the keyword search instead *does* produce results though.
Does anyone have any ideas what might cause this? I've tested it on
Bywater's demo, which is running 20.05.04, and it does work there, so I'm
guessing it's some quirk specific to our system rather than an actual bug
(unless it happened to be introduced between the .04 and .08 releases).
Here's our server specs:
Koha version: 20.05.08.000
OS version ('uname -a'): Linux ccflskoha.ccfls.org 4.15.0-135-generic
#139-Ubuntu SMP Mon Jan 18 17:38:24 UTC 2021 x86_64
Perl interpreter: /usr/bin/perl
Perl version: 5.026001
Perl @INC: /usr/share/koha/lib
/usr/share/koha/installer
/usr/share/koha/lib/installer
/etc/perl
/usr/local/lib/x86_64-linux-gnu/perl/5.26.1
/usr/local/share/perl/5.26.1
/usr/lib/x86_64-linux-gnu/perl5/5.26
/usr/share/perl5
/usr/lib/x86_64-linux-gnu/perl/5.26
/usr/share/perl/5.26
/usr/local/lib/site_perl
/usr/lib/x86_64-linux-gnu/perl-base
/var/lib/koha/ccfls/plugins
MySQL version: mysql Ver 15.1 Distrib 10.4.17-MariaDB, for debian-linux-gnu
(x86_64) using readline 5.2
Apache version: Server version: Apache/2.4.29 (Ubuntu)
PSGI: Plack (deployment)
Memcached: Servers: 127.0.0.1:11211 | Namespace: koha_ccfls | Status:
running. | Config read from: koha-conf.xml
Zebra version: Zebra 2.0.59 (C) 1994-2014, Index Data Zebra is free
software, covered by the GNU General Public License, and you are welcome to
change it and/or distribute copies of it under certain conditions. SHA1 ID:
c00bfddbf0f3608340d61298acc61dafb167f9b2 Using ICU
Date and time: 02/04/2021 11:16
Time zone: Used: America/New_York | Config: Undefined | Environment (TZ):
Undefined
Many thanks,
Cindy
---
Cindy Murdock Ames
IT Services Director
Meadville Public Library | CCFLS
https://meadvillelibrary.org | https://ccfls.org
___
Koha mailing list http://koha-community.org
Koha@lists.katipo.co.nz
Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha
Re: [Koha] Koha 20.05, Ubuntu 18.04 and MariaDB
Hi Jonathan, No, we only have 9 libraries so there should only be 11 entries in that table (we have two rotating collections we treat as "branches" as well). Cindy ------- Cindy Murdock Ames IT Services Director Meadville Public Library | CCFLS https://meadvillelibrary.org | https://ccfls.org Please report tech support issues in Mantis: https://mantis.ccfls.org On Thu, Jul 30, 2020 at 3:29 AM Jonathan Druart < jonathan.dru...@bugs.koha-community.org> wrote: > Hello Cindy, > We faced this error for the table borrowers (bug 24986). > I am quite surprised you got it for the branches table, especially for > a "DROP COLUMN" statement. > Do you have a ton of entries in this table? > Regards, > Jonathan > > Le mer. 29 juil. 2020 à 19:05, Cindy Murdock Ames a > écrit : > > > > I've been running 19.11.05 for several months now with MariaDB 10.4.13 > with > > no issues AFAIK. I upgraded a test server to 20.05 and got some errors > > from updatedatabase.pl like this: > > > > DBD::mysql::db do failed: Row size too large. The maximum row size for > the > > used table type, not counting BLOBs, is 8126. This includes storage > > overhead, check the manual. You have to change some columns to TEXT or > > BLOBs > > [for Statement "ALTER TABLE branches DROP COLUMN branchprinter"] at > > /usr/share/koha/intranet/cgi-bin/installer/data/mysql/updatedatabase.pl > > line 21074. > > > > After some investigating I found that our database (imported from 3.22 in > > April) had a row_format of "Compact" on all tables and newer versions of > > the database have a row_format of "Dynamic". I expect this is cruft from > > our database that has been imported into new versions of Koha several > > times, since we've been using Koha for 10+ years. Anyway, on my test > > server I changed ours to Dynamic and it was able to update without any > > errors after that, but I haven't yet upgraded our production server to > it. > > Probably no one else will run into this, but I thought I'd just put it > out > > into the ether in case anyone else runs into this issue. > > > > Cindy > > > > --- > > Cindy Murdock Ames > > IT Services Director > > Meadville Public Library | CCFLS > > https://meadvillelibrary.org | https://ccfls.org > > > > > > > > > > On Mon, Jul 27, 2020 at 11:24 AM Philippe Blouin < > > philippe.blo...@inlibro.com> wrote: > > > > > I only dared to write that affirmatively because I was just in the > > > process of updating another machine (from 9.9 to 9.13), and it was > > > installing MariaDB 10.4.13. > > > > > > It was right in front of me, on my screen. > > > > > > But after your answers I dug a bit and yeah, the source.list.d > specifies > > > 10.4 for mariadb. > > > > > > So my initial answer is mostly wrong. The only correct part is that we > > > do have multiple production systems running 10.4 without glitch, but > > > that is not proof of anything. > > > > > > My apologies for the misleading answer. > > > > > > Philippe Blouin, > > > Directeur de la technologie > > > > > > Tél. : (833) 465-4276, poste 230 > > > philippe.blo...@inlibro.com <mailto:philippe.blo...@inlibro.com> > > > > > > inLibro | pour esprit libre | www.inLibro.com <http://www.inLibro.com> > > > On 2020-07-27 10:56 a.m., Michael Kuhn wrote: > > > > Hi Philippe > > > > > > > > Am 27.07.20 um 16:32 schrieb Philippe Blouin: > > > > > 10.4 is the default mariadb version you get with an up-to-date > Debian > > > > > 9 or Ubuntu 18. > > > > > > > > > > It works. > > > > > > > > I just updated another Installation of Debian GNU/Linux 9.12 to 9.13. > > > > But it only updated to MariaDB 10.1.45, not 10.4.x > > > > > > > > So my question is still open, if Koha 18.11 on Debian 9 will work > with > > > > Koha 10.3 > > > > > > > > Best wishes: Michael > > > ___ > > > > > > Koha mailing list http://koha-community.org > > > Koha@lists.katipo.co.nz > > > Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha > > > > > ___ > > > > Koha mailing list http://koha-community.org > > Koha@lists.katipo.co.nz > > Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha > ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha
Re: [Koha] Koha 20.05, Ubuntu 18.04 and MariaDB
I've been running 19.11.05 for several months now with MariaDB 10.4.13 with no issues AFAIK. I upgraded a test server to 20.05 and got some errors from updatedatabase.pl like this: DBD::mysql::db do failed: Row size too large. The maximum row size for the used table type, not counting BLOBs, is 8126. This includes storage overhead, check the manual. You have to change some columns to TEXT or BLOBs [for Statement "ALTER TABLE branches DROP COLUMN branchprinter"] at /usr/share/koha/intranet/cgi-bin/installer/data/mysql/updatedatabase.pl line 21074. After some investigating I found that our database (imported from 3.22 in April) had a row_format of "Compact" on all tables and newer versions of the database have a row_format of "Dynamic". I expect this is cruft from our database that has been imported into new versions of Koha several times, since we've been using Koha for 10+ years. Anyway, on my test server I changed ours to Dynamic and it was able to update without any errors after that, but I haven't yet upgraded our production server to it. Probably no one else will run into this, but I thought I'd just put it out into the ether in case anyone else runs into this issue. Cindy ----------- Cindy Murdock Ames IT Services Director Meadville Public Library | CCFLS https://meadvillelibrary.org | https://ccfls.org On Mon, Jul 27, 2020 at 11:24 AM Philippe Blouin < philippe.blo...@inlibro.com> wrote: > I only dared to write that affirmatively because I was just in the > process of updating another machine (from 9.9 to 9.13), and it was > installing MariaDB 10.4.13. > > It was right in front of me, on my screen. > > But after your answers I dug a bit and yeah, the source.list.d specifies > 10.4 for mariadb. > > So my initial answer is mostly wrong. The only correct part is that we > do have multiple production systems running 10.4 without glitch, but > that is not proof of anything. > > My apologies for the misleading answer. > > Philippe Blouin, > Directeur de la technologie > > Tél. : (833) 465-4276, poste 230 > philippe.blo...@inlibro.com <mailto:philippe.blo...@inlibro.com> > > inLibro | pour esprit libre | www.inLibro.com <http://www.inLibro.com> > On 2020-07-27 10:56 a.m., Michael Kuhn wrote: > > Hi Philippe > > > > Am 27.07.20 um 16:32 schrieb Philippe Blouin: > > > 10.4 is the default mariadb version you get with an up-to-date Debian > > > 9 or Ubuntu 18. > > > > > > It works. > > > > I just updated another Installation of Debian GNU/Linux 9.12 to 9.13. > > But it only updated to MariaDB 10.1.45, not 10.4.x > > > > So my question is still open, if Koha 18.11 on Debian 9 will work with > > Koha 10.3 > > > > Best wishes: Michael > ___ > > Koha mailing list http://koha-community.org > Koha@lists.katipo.co.nz > Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha > ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha
Re: [Koha] temporarily suspend fines
You could mark the extended period as a holiday. That's what we'll be doing if we have to close. Regards, Cindy --- Cindy Murdock Ames IT Services Director Meadville Public Library | CCFLS https://meadvillelibrary.org | https://ccfls.org Please report tech support issues in Mantis: https://mantis.ccfls.org On Fri, Mar 13, 2020 at 1:02 PM Margo Duncan wrote: > Good morning, > > Our spring break has been extended and we would like to temporarily > suspend fines or automatically extend due dates in Koha, instead of > individually adjusting accounts. > > Is there a way to do this globally? We have a lot of circulation rules. > > Thanks in advance, > Margo > > Margo Duncan, MLS > Electronic Resources & Collection Development Librarian > Robert R. Muntz Library > The University of Texas at Tyler > 903.566.7174 | mdun...@uttyler.edu<mailto:mdun...@uttyler.edu> > > ___ > > Koha mailing list http://koha-community.org > Koha@lists.katipo.co.nz > Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha > ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha
Re: [Koha] Warning about patron relationship problems?
Hi Alvaro, Someone please correct me if I'm wrong, but I think you can apply the patch without affecting package updates (I think it would just overwrite about.pl with the new version when you upgrade). I just applied it manually on my test server (since there were few changes I just made the changes in a text editor) and it seems to have worked. It's probably safe because you're only changing one file, and you can save a copy of the original if you want in case it breaks the package update, and put it back in place before doing the upgrade to 19.11.02. Thanks all for the fix! Cindy --- Cindy Murdock Ames IT Services Director Meadville Public Library | CCFLS https://meadvillelibrary.org | https://ccfls.org Please report tech support issues in Mantis: https://mantis.ccfls.org On Wed, Jan 8, 2020 at 8:54 PM Alvaro Cornejo wrote: > Hi Martin, > > I have the same problem ad I saw that the patch was pushed to 19.11.02 > > When does it will be available? Or can I apply the patch without breaking > apt-get update/upgrade? > > Regards, > > Alvaro > > > |-| > Envíe y Reciba Datos y mensajes de Texto (SMS) hacia y desde cualquier > celular y Nextel > en el Perú, México y en mas de 180 paises. Use aplicaciones 2 vias via SMS > y GPRS online > Visitenos en www.perusms.com > > > Le mer. 11 déc. 2019 à 06:39, Renvoize, Martin < > martin.renvo...@ptfs-europe.com> a écrit : > >> I've added a bug (and patch): >> https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24215. >> >> *Martin Renvoize* >> >> <https://www.ptfs-europe.com> >> >> Development Team Manager >> >> >> >> >> >> *Phone:* +44 (0) 1483 378728 >> >> *Mobile:* +44 (0) 7725 985 636 >> >> *Email:* martin.renvo...@ptfs-europe.com >> >> *Fax:* +44 (0) 800 756 6384 >> >> >> www.ptfs-europe.com >> >> >> >> >> >> >> >> Registered in the United Kingdom No. 06416372 VAT Reg No. 925 7211 30 >> >> The information contained in this email message may be privileged, >> confidential and protected from disclosure. If you are not the intended >> recipient, any dissemination, distribution or copying is strictly >> prohibited. If you think that you have received this email message in >> error, please email the sender at i...@ptfs-europe.com >> >> >> >> On Wed, 11 Dec 2019 at 10:43, Renvoize, Martin < >> martin.renvo...@ptfs-europe.com> wrote: >> >> > This looks like a bug to me, you should not see ARRAY but rather see a >> > relationship name that exists in your database table but does not yet >> exist >> > in the system preference. >> > >> > I'll take a look and file a bug for it. >> > >> > *Martin Renvoize* >> > >> > <https://www.ptfs-europe.com> >> > >> > Development Team Manager >> > >> > >> > >> > >> > >> > *Phone:* +44 (0) 1483 378728 >> > >> > *Mobile:* +44 (0) 7725 985 636 >> > >> > *Email:* martin.renvo...@ptfs-europe.com >> > >> > *Fax:* +44 (0) 800 756 6384 >> > >> > >> > www.ptfs-europe.com >> > >> > >> > >> > >> > >> > >> > >> > Registered in the United Kingdom No. 06416372 VAT Reg No. 925 7211 30 >> > >> > The information contained in this email message may be privileged, >> > confidential and protected from disclosure. If you are not the intended >> > recipient, any dissemination, distribution or copying is strictly >> > prohibited. If you think that you have received this email message in >> > error, please email the sender at i...@ptfs-europe.com >> > >> > >> > >> > On Wed, 4 Dec 2019 at 16:40, Cindy Murdock Ames >> > wrote: >> > >> >> Hi all, >> >> >> >> I have a test instance of Koha with my libraries' data, originally >> 19.05 >> >> but I upgraded it to 19.11 yesterday, so I don't know if this message >> was >> >> there before as I just noticed the warnings of potential problems on >> the >> >> About page under the System Information tab (nice btw!), and I have the >> >> following notice there: >> >> >> >> The following values have been used for guara
Re: [Koha] Warning about patron relationship problems?
Thanks Martin! Let me know if there's anything I can do to help. --- Cindy Murdock Ames IT Services Director Meadville Public Library | CCFLS https://meadvillelibrary.org | https://ccfls.org Please report tech support issues in Mantis: https://mantis.ccfls.org On Wed, Dec 11, 2019 at 5:43 AM Renvoize, Martin < martin.renvo...@ptfs-europe.com> wrote: > This looks like a bug to me, you should not see ARRAY but rather see a > relationship name that exists in your database table but does not yet exist > in the system preference. > > I'll take a look and file a bug for it. > > *Martin Renvoize* > > <https://www.ptfs-europe.com> > > Development Team Manager > > > > > > *Phone:* +44 (0) 1483 378728 > > *Mobile:* +44 (0) 7725 985 636 > > *Email:* martin.renvo...@ptfs-europe.com > > *Fax:* +44 (0) 800 756 6384 > > > www.ptfs-europe.com > > > > > > > > Registered in the United Kingdom No. 06416372 VAT Reg No. 925 7211 30 > > The information contained in this email message may be privileged, > confidential and protected from disclosure. If you are not the intended > recipient, any dissemination, distribution or copying is strictly > prohibited. If you think that you have received this email message in > error, please email the sender at i...@ptfs-europe.com > > > > On Wed, 4 Dec 2019 at 16:40, Cindy Murdock Ames > wrote: > >> Hi all, >> >> I have a test instance of Koha with my libraries' data, originally 19.05 >> but I upgraded it to 19.11 yesterday, so I don't know if this message was >> there before as I just noticed the warnings of potential problems on the >> About page under the System Information tab (nice btw!), and I have the >> following notice there: >> >> The following values have been used for guarantee/guarantor relationships, >> but do not exist in the 'borrowerRelationship' system preference: >> >> ARRAY(0x55f2846812d0) >> >> What does that ARRAY warning mean? Here's my original values in >> borrower_relationships.relationship: >> >> ++ >> | relationship| >> ++ >> | parent/guardian | >> | grandparent| >> | tss | >> ++ >> >> And here's the values in the relationship field in borrowers: >> MariaDB [Koha]> select relationship, count(*) from borrowers group by >> relationship; >> ++--+ >> | relationship| count(*) | >> ++--+ >> | NULL |34031 | >> | grandparent| 161 | >> | parent/guardian | 5552 | >> | tss| 11 | >> ++--+ >> >> With the exception of NULL, those are the values in the >> borrowerRelationship syspref, separated by pipes (|). I thought maybe the >> slash in "parent/guardian" was the issue, so I tried changing it to >> "parent >> or guardian" but the ARRAY(0x55f2846812d0) warning is still there. What >> on >> earth is it? I googled and looked in the bug list but didn't find anything >> pertinent. >> >> Thanks all! And thanks for 19.11! >> >> Cindy >> >> --- >> Cindy Murdock Ames >> IT Services Director >> Meadville Public Library | CCFLS >> https://meadvillelibrary.org | https://ccfls.org >> >> Please report tech support issues in Mantis: https://mantis.ccfls.org >> ___ >> Koha mailing list http://koha-community.org >> Koha@lists.katipo.co.nz >> https://lists.katipo.co.nz/mailman/listinfo/koha >> > ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
[Koha] Warning about patron relationship problems?
Hi all, I have a test instance of Koha with my libraries' data, originally 19.05 but I upgraded it to 19.11 yesterday, so I don't know if this message was there before as I just noticed the warnings of potential problems on the About page under the System Information tab (nice btw!), and I have the following notice there: The following values have been used for guarantee/guarantor relationships, but do not exist in the 'borrowerRelationship' system preference: ARRAY(0x55f2846812d0) What does that ARRAY warning mean? Here's my original values in borrower_relationships.relationship: ++ | relationship| ++ | parent/guardian | | grandparent| | tss | ++ And here's the values in the relationship field in borrowers: MariaDB [Koha]> select relationship, count(*) from borrowers group by relationship; ++--+ | relationship| count(*) | ++--+ | NULL |34031 | | grandparent| 161 | | parent/guardian | 5552 | | tss| 11 | ++--+ With the exception of NULL, those are the values in the borrowerRelationship syspref, separated by pipes (|). I thought maybe the slash in "parent/guardian" was the issue, so I tried changing it to "parent or guardian" but the ARRAY(0x55f2846812d0) warning is still there. What on earth is it? I googled and looked in the bug list but didn't find anything pertinent. Thanks all! And thanks for 19.11! Cindy ------- Cindy Murdock Ames IT Services Director Meadville Public Library | CCFLS https://meadvillelibrary.org | https://ccfls.org Please report tech support issues in Mantis: https://mantis.ccfls.org ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
Re: [Koha] z39 no connection
We have noticed it here too, beginning yesterday. Cindy --- Cindy Murdock Ames IT Services Director Meadville Public Library | CCFLS http://meadvillelibrary.org | http://ccfls.org On Tue, Oct 27, 2015 at 6:12 AM, Mary W. Maina <mmaina...@gmail.com> wrote: > Hi people, > > we are experiencing problems with the z39serach we get > >- Connection failed to lx2.loc.gov > > are the servers down? or is it an internal problem from our side. > > > Mary > ___ > Koha mailing list http://koha-community.org > Koha@lists.katipo.co.nz > https://lists.katipo.co.nz/mailman/listinfo/koha > ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
Re: [Koha] Fwd: Facets missing on fresh dev install of 3.18.3
Hi everybody, Thank you guys, you are awesome!!! Removing the Indexdata packages and installing the versions from the Wheezy repos worked! Facets are working! :D :D :D Cindy --- Cindy Murdock Ames IT Services Director Meadville Public Library | CCFLS http://meadvillelibrary.org | http://ccfls.org On Tue, Feb 3, 2015 at 2:42 PM, Katrin Fischer katrin.fischer...@web.de wrote: Hi Cindy, we figured out the problem now - it's related to the Zebra version. I removed Indexdata's repos now and reinstalled everything. Using 2.0.44-3.1 now and facets are working! Katrin Am 03.02.2015 um 19:25 schrieb Cindy Murdock Ames: Yep, with use_zebra_facets=0 I can see author facets: http://imgur.com/lj7v0Uw And thanks Katrin, I'm sorry you're having the same problem but it makes me feel a bit better knowing that it's not just me! --- Cindy Murdock Ames IT Services Director Meadville Public Library | CCFLS http://meadvillelibrary.org | http://ccfls.org Please report tech support issues in Mantis: http://tracker.ccfls.org/mantis On Tue, Feb 3, 2015 at 12:22 PM, Tomas Cohen Arazi tomasco...@gmail.com wrote: If you perform the same search, making sure use_zebra_facets=0, do u see author facets? On Tue, Feb 3, 2015 at 1:12 PM, Cindy Murdock Ames cmurd...@ccfls.org wrote: Okay, here's the yaz-client output: kohaclone@koha:~$ yaz-client unix:/home/kohaclone/koha-dev/var/run/zebradb/bibliosocket Connecting...OK. Sent initrequest. Connection accepted by v3 target. ID : 81 Name : Zebra Information Server/GFS/YAZ Version: 2.0.59/5.9.0 5c3d5999d1588a3963435412af22ec993b22e391 Options: search present delSet triggerResourceCtrl scan sort extendedServices namedResultSets Elapsed: 0.002689 Z base biblios Z format xml Z elem zebra::facet::au:0:100 Z f @attrset Bib-1 @or @or @or @or @or @attr 1=36 @attr 4=1 @attr 6=3 @attr 9=32 @attr 2=102 mark twain @attr 1=4 @attr 4=1 @attr 6=3 @attr 9=28 @attr 2=102 mark twain @attr 1=36 @attr 4=1 @attr 9=26 @attr 2=102 mark twain @attr 1=4 @attr 4=6 @attr 9=24 @attr 2=102 mark twain @attr 4=6 @attr 5=1 @attr 9=14 @attr 2=102 mark? twain? @attr 4=6 @attr 9=14 @attr 2=102 mark twain Sent searchRequest. Received SearchResponse. Search was a success. Number of hits: 456, setno 1 SearchResult-1: term=mark twain cnt=16, term=mark twain cnt=16, term=mark cnt=215, term=twain cnt=97, term=mark cnt=2018, term=twain cnt=374, term=mark cnt=5366, term=twain cnt=480, term=mark cnt=3033, term=twain cnt=478 records returned: 0 Elapsed: 0.020487 Z s 1+1 Sent presentRequest (1+1). Records: 1 Diagnostic message(s) from database: [25] Specified element set name not valid for specified database -- v2 addinfo '' nextResultSetPosition = 2 Elapsed: 0.000495 Z --- Cindy Murdock Ames IT Services Director Meadville Public Library | CCFLS http://meadvillelibrary.org | http://ccfls.org Please report tech support issues in Mantis: http://tracker.ccfls.org/mantis On Tue, Feb 3, 2015 at 11:07 AM, Cindy Murdock Ames cmurd...@ccfls.org wrote: Thanks Tomas and Kyle for the clarification, sorry for the misinterpretation. Here's the output from zebra when I start it manually and do a search in the catalog: 11:00:43-03/02 zebrasrv(3) [session] Session - OK 3 unix:/home/kohaclone/koha-dev/var/run/zebradb/bibliosocket PID=23191 11:00:43-03/02 zebrasrv(3) [request] Auth idPass kohaclone - 11:00:43-03/02 zebrasrv(3) [request] Init OK - ID:81 Name:ZOOM-C/YAZ Version:5.9.0 5c3d5999d1588a3963435412af22ec993b22e391 11:00:43-03/02 zebrasrv(3) [log] dict_lookup_grep: (\x01\x1C)(m(a|\xC3\xA1|\xC3\xA0|\xC3\xA3|\xC3\xA5|\xC3\xA2|\xC4\x83|\xC4\x85|\xC8\xA7|\xC7\x8E|\xC8\x81|\xC8\x83)rk\ tw(a|\xC3\xA1|\xC3\xA0|\xC3\xA3|\xC3\xA5|\xC3\xA2|\xC4\x83|\xC4\x85|\xC8\xA7|\xC7\x8E|\xC8\x81|\xC8\x83)(i|\xC3\xAD|\xC3\xAC|\xC3\xAE|\xE1\xBB\x8B|\xC4\xA9|\xC4\xAD|\xC4\xAF|\xC7\x90|\xC8\x89|\xC8\x8B)n) 11:00:43-03/02 zebrasrv(3) [log] dict_lookup_grep: (\x01 )(m(a|\xC3\xA1|\xC3\xA0|\xC3\xA3|\xC3\xA5|\xC3\xA2|\xC4\x83|\xC4\x85|\xC8\xA7|\xC7\x8E|\xC8\x81|\xC8\x83)rk\ tw(a|\xC3\xA1|\xC3\xA0|\xC3\xA3|\xC3\xA5|\xC3\xA2|\xC4\x83|\xC4\x85|\xC8\xA7|\xC7\x8E|\xC8\x81|\xC8\x83)(i|\xC3\xAD|\xC3\xAC|\xC3\xAE|\xE1\xBB\x8B|\xC4\xA9|\xC4\xAD|\xC4\xAF|\xC7\x90|\xC8\x89|\xC8\x8B)n) 11:00:43-03/02 zebrasrv(3) [log] dict_lookup_grep: (\x01\x1A)(m(a|\xC3\xA1|\xC3\xA0|\xC3\xA3|\xC3\xA5|\xC3\xA2|\xC4\x83|\xC4\x85|\xC8\xA7|\xC7\x8E|\xC8\x81|\xC8\x83)rk) 11:00:43-03/02 zebrasrv(3) [log] dict_lookup_grep: (\x01\x1A)(tw(a|\xC3\xA1|\xC3\xA0|\xC3\xA3|\xC3\xA5|\xC3\xA2|\xC4\x83|\xC4\x85|\xC8\xA7|\xC7\x8E|\xC8\x81|\xC8\x83)(i|\xC3\xAD|\xC3\xAC|\xC3\xAE|\xE1\xBB\x8B|\xC4\xA9|\xC4
Re: [Koha] Fwd: Facets missing on fresh dev install of 3.18.3
Hi everybody, To answer a bunch of questions: Yes, setting use_zebra_facets to 0 (and restarting memcached in my case) does bring the facets back. As far as I know doing that reverts facets to the old system that uses grs1. I would prefer to be able to use dom as grs1 is being deprecated, from what I've read. This server isn't being used in production yet (but hopefully soon) so I would rather be able to use the zebra facets. The facets are also missing from the staff interface. My zebra version is 2.0.59-1.indexdata. My dev install is running on Debian Wheezy, and I'm using the git tag for 3.18.3. As for logs: koha-opac-error_log doesn't log anything at all when I do a search. koha-zebradaemon-output.log outputs this every time I try a search: 10:03:42-03/02 zebrasrv(3) [warn] ir_session (exception). Is there a way to enable more verbose logging? And do search results revert to grs1 if dom indexing isn't working? I suspect it's something to do with dom, but I don't know enough about zebra to test my hypothesis. Regards, Cindy --- Cindy Murdock Ames IT Services Director Meadville Public Library | CCFLS http://meadvillelibrary.org | http://ccfls.org On Tue, Feb 3, 2015 at 9:40 AM, Tomas Cohen Arazi tomasco...@gmail.com wrote: El Mon Feb 02 2015 at 15:06:00, Cindy Murdock Ames (cmurd...@ccfls.org) escribió: Hi Michał, The opac isn't publicly accessible yet but here's a screenshot: http://i.imgur.com/0hdHrbm.png The area where the facets usually are is completely blank, even the Refine your search header is missing. We are using marc21, the xsl, xml record.abs files are present in my installation and the zebra configuration files look like they're pointing to them correctly. I haven't edited them at all. I do have logs from my last reindexing here: http://ccfls.org/files/reindex-output-1-28-15.txt. Does setting use_zebra_facets0/use_zebra_facets make them show? Regards ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Re: [Koha] Fwd: Facets missing on fresh dev install of 3.18.3
-03/02 zebrasrv(3) [request] Present OK - 1 19+1 11:00:43-03/02 zebrasrv(3) [request] Present OK - 1 20+1 11:00:43-03/02 zebrasrv(3) [request] Present OK - 1 1+1 11:00:43-03/02 zebrasrv(3) [request] Present OK - 1 1+1 11:00:43-03/02 zebrasrv(3) [request] Present OK - 1 1+1 11:00:43-03/02 zebrasrv(3) [request] Present OK - 1 1+1 11:00:43-03/02 zebrasrv(3) [request] Present OK - 1 1+1 11:00:43-03/02 zebrasrv(3) [request] Present OK - 1 1+1 11:00:43-03/02 zebrasrv(3) [request] Present OK - 1 1+1 11:00:43-03/02 zebrasrv(3) [request] Present OK - 1 1+1 11:00:43-03/02 zebrasrv(3) [request] Present OK - 1 1+1 11:00:44-03/02 zebrasrv(3) [session] Connection closed by client 11:00:44-03/02 zebrasrv(3) [warn] ir_session (exception) I don't see anything there mentioning facets. Stay tuned for the yaz-client test... Cindy --- Cindy Murdock Ames IT Services Director Meadville Public Library | CCFLS http://meadvillelibrary.org | http://ccfls.org Please report tech support issues in Mantis: http://tracker.ccfls.org/mantis On Tue, Feb 3, 2015 at 10:48 AM, Kyle Hall kyle.m.h...@gmail.com wrote: On Tue, Feb 3, 2015 at 10:12 AM, Cindy Murdock Ames cmurd...@ccfls.org wrote: Hi everybody, To answer a bunch of questions: Yes, setting use_zebra_facets to 0 (and restarting memcached in my case) does bring the facets back. As far as I know doing that reverts facets to the old system that uses grs1. I would prefer to be able to use dom as grs1 is being deprecated, from what I've read. This server isn't being used in production yet (but hopefully soon) so I would rather be able to use the zebra facets. This isn't quite accurate. The old facet system isn't dependent on grs vs dom. What it does is generate the facets by reading X records of the search results ( not just the results displayed to the searcher ). From those it creates the facets. Unless this code is planned to be obsoleted ( which I am unaware of ), using zebra facets is not required. However, the benefit of zebra facets is that they are more accurate, and create the facets on the entire result set, rather than a portion of the results, and I imagine it's also faster as well. Kyle ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Re: [Koha] Fwd: Facets missing on fresh dev install of 3.18.3
Okay, here's the yaz-client output: kohaclone@koha:~$ yaz-client unix:/home/kohaclone/koha-dev/var/run/zebradb/bibliosocket Connecting...OK. Sent initrequest. Connection accepted by v3 target. ID : 81 Name : Zebra Information Server/GFS/YAZ Version: 2.0.59/5.9.0 5c3d5999d1588a3963435412af22ec993b22e391 Options: search present delSet triggerResourceCtrl scan sort extendedServices namedResultSets Elapsed: 0.002689 Z base biblios Z format xml Z elem zebra::facet::au:0:100 Z f @attrset Bib-1 @or @or @or @or @or @attr 1=36 @attr 4=1 @attr 6=3 @attr 9=32 @attr 2=102 mark twain @attr 1=4 @attr 4=1 @attr 6=3 @attr 9=28 @attr 2=102 mark twain @attr 1=36 @attr 4=1 @attr 9=26 @attr 2=102 mark twain @attr 1=4 @attr 4=6 @attr 9=24 @attr 2=102 mark twain @attr 4=6 @attr 5=1 @attr 9=14 @attr 2=102 mark? twain? @attr 4=6 @attr 9=14 @attr 2=102 mark twain Sent searchRequest. Received SearchResponse. Search was a success. Number of hits: 456, setno 1 SearchResult-1: term=mark twain cnt=16, term=mark twain cnt=16, term=mark cnt=215, term=twain cnt=97, term=mark cnt=2018, term=twain cnt=374, term=mark cnt=5366, term=twain cnt=480, term=mark cnt=3033, term=twain cnt=478 records returned: 0 Elapsed: 0.020487 Z s 1+1 Sent presentRequest (1+1). Records: 1 Diagnostic message(s) from database: [25] Specified element set name not valid for specified database -- v2 addinfo '' nextResultSetPosition = 2 Elapsed: 0.000495 Z --- Cindy Murdock Ames IT Services Director Meadville Public Library | CCFLS http://meadvillelibrary.org | http://ccfls.org Please report tech support issues in Mantis: http://tracker.ccfls.org/mantis On Tue, Feb 3, 2015 at 11:07 AM, Cindy Murdock Ames cmurd...@ccfls.org wrote: Thanks Tomas and Kyle for the clarification, sorry for the misinterpretation. Here's the output from zebra when I start it manually and do a search in the catalog: 11:00:43-03/02 zebrasrv(3) [session] Session - OK 3 unix:/home/kohaclone/koha-dev/var/run/zebradb/bibliosocket PID=23191 11:00:43-03/02 zebrasrv(3) [request] Auth idPass kohaclone - 11:00:43-03/02 zebrasrv(3) [request] Init OK - ID:81 Name:ZOOM-C/YAZ Version:5.9.0 5c3d5999d1588a3963435412af22ec993b22e391 11:00:43-03/02 zebrasrv(3) [log] dict_lookup_grep: (\x01\x1C)(m(a|\xC3\xA1|\xC3\xA0|\xC3\xA3|\xC3\xA5|\xC3\xA2|\xC4\x83|\xC4\x85|\xC8\xA7|\xC7\x8E|\xC8\x81|\xC8\x83)rk\ tw(a|\xC3\xA1|\xC3\xA0|\xC3\xA3|\xC3\xA5|\xC3\xA2|\xC4\x83|\xC4\x85|\xC8\xA7|\xC7\x8E|\xC8\x81|\xC8\x83)(i|\xC3\xAD|\xC3\xAC|\xC3\xAE|\xE1\xBB\x8B|\xC4\xA9|\xC4\xAD|\xC4\xAF|\xC7\x90|\xC8\x89|\xC8\x8B)n) 11:00:43-03/02 zebrasrv(3) [log] dict_lookup_grep: (\x01 )(m(a|\xC3\xA1|\xC3\xA0|\xC3\xA3|\xC3\xA5|\xC3\xA2|\xC4\x83|\xC4\x85|\xC8\xA7|\xC7\x8E|\xC8\x81|\xC8\x83)rk\ tw(a|\xC3\xA1|\xC3\xA0|\xC3\xA3|\xC3\xA5|\xC3\xA2|\xC4\x83|\xC4\x85|\xC8\xA7|\xC7\x8E|\xC8\x81|\xC8\x83)(i|\xC3\xAD|\xC3\xAC|\xC3\xAE|\xE1\xBB\x8B|\xC4\xA9|\xC4\xAD|\xC4\xAF|\xC7\x90|\xC8\x89|\xC8\x8B)n) 11:00:43-03/02 zebrasrv(3) [log] dict_lookup_grep: (\x01\x1A)(m(a|\xC3\xA1|\xC3\xA0|\xC3\xA3|\xC3\xA5|\xC3\xA2|\xC4\x83|\xC4\x85|\xC8\xA7|\xC7\x8E|\xC8\x81|\xC8\x83)rk) 11:00:43-03/02 zebrasrv(3) [log] dict_lookup_grep: (\x01\x1A)(tw(a|\xC3\xA1|\xC3\xA0|\xC3\xA3|\xC3\xA5|\xC3\xA2|\xC4\x83|\xC4\x85|\xC8\xA7|\xC7\x8E|\xC8\x81|\xC8\x83)(i|\xC3\xAD|\xC3\xAC|\xC3\xAE|\xE1\xBB\x8B|\xC4\xA9|\xC4\xAD|\xC4\xAF|\xC7\x90|\xC8\x89|\xC8\x8B)n) 11:00:43-03/02 zebrasrv(3) [log] dict_lookup_grep: (\x01\x1E)(m(a|\xC3\xA1|\xC3\xA0|\xC3\xA3|\xC3\xA5|\xC3\xA2|\xC4\x83|\xC4\x85|\xC8\xA7|\xC7\x8E|\xC8\x81|\xC8\x83)rk) 11:00:43-03/02 zebrasrv(3) [log] dict_lookup_grep: (\x01\x1E)(tw(a|\xC3\xA1|\xC3\xA0|\xC3\xA3|\xC3\xA5|\xC3\xA2|\xC4\x83|\xC4\x85|\xC8\xA7|\xC7\x8E|\xC8\x81|\xC8\x83)(i|\xC3\xAD|\xC3\xAC|\xC3\xAE|\xE1\xBB\x8B|\xC4\xA9|\xC4\xAD|\xC4\xAF|\xC7\x90|\xC8\x89|\xC8\x8B)n) 11:00:43-03/02 zebrasrv(3) [log] dict_lookup_grep: (\x01l\x01\x02)(m(a|\xC3\xA1|\xC3\xA0|\xC3\xA3|\xC3\xA5|\xC3\xA2|\xC4\x83|\xC4\x85|\xC8\xA7|\xC7\x8E|\xC8\x81|\xC8\x83)rk.*) 11:00:43-03/02 zebrasrv(3) [log] dict_lookup_grep: (\x01l\x01\x02)(tw(a|\xC3\xA1|\xC3\xA0|\xC3\xA3|\xC3\xA5|\xC3\xA2|\xC4\x83|\xC4\x85|\xC8\xA7|\xC7\x8E|\xC8\x81|\xC8\x83)(i|\xC3\xAD|\xC3\xAC|\xC3\xAE|\xE1\xBB\x8B|\xC4\xA9|\xC4\xAD|\xC4\xAF|\xC7\x90|\xC8\x89|\xC8\x8B)n.*) 11:00:43-03/02 zebrasrv(3) [log] dict_lookup_grep: (\x01l\x01\x02)(m(a|\xC3\xA1|\xC3\xA0|\xC3\xA3|\xC3\xA5|\xC3\xA2|\xC4\x83|\xC4\x85|\xC8\xA7|\xC7\x8E|\xC8\x81|\xC8\x83)rk) 11:00:43-03/02 zebrasrv(3) [log] dict_lookup_grep: (\x01l\x01\x02)(tw(a|\xC3\xA1|\xC3\xA0|\xC3\xA3|\xC3\xA5|\xC3\xA2|\xC4\x83|\xC4\x85|\xC8\xA7|\xC7\x8E|\xC8\x81|\xC8\x83)(i|\xC3\xAD|\xC3\xAC|\xC3\xAE|\xE1\xBB\x8B|\xC4\xA9|\xC4\xAD|\xC4\xAF|\xC7\x90|\xC8\x89|\xC8\x8B)n) 11:00:43-03/02 zebrasrv(3) [log] or op sum_cur=1.0 sum_tot=8472.0 hits=1.00 11:00:43-03/02 zebrasrv(3) [log] or op sum_cur=1.0 sum_tot=1141.0 hits=1.00 11:00:43-03/02 zebrasrv(3) [log] or op sum_cur=0.0
Re: [Koha] Fwd: Facets missing on fresh dev install of 3.18.3
Yep, with use_zebra_facets=0 I can see author facets: http://imgur.com/lj7v0Uw And thanks Katrin, I'm sorry you're having the same problem but it makes me feel a bit better knowing that it's not just me! --- Cindy Murdock Ames IT Services Director Meadville Public Library | CCFLS http://meadvillelibrary.org | http://ccfls.org Please report tech support issues in Mantis: http://tracker.ccfls.org/mantis On Tue, Feb 3, 2015 at 12:22 PM, Tomas Cohen Arazi tomasco...@gmail.com wrote: If you perform the same search, making sure use_zebra_facets=0, do u see author facets? On Tue, Feb 3, 2015 at 1:12 PM, Cindy Murdock Ames cmurd...@ccfls.org wrote: Okay, here's the yaz-client output: kohaclone@koha:~$ yaz-client unix:/home/kohaclone/koha-dev/var/run/zebradb/bibliosocket Connecting...OK. Sent initrequest. Connection accepted by v3 target. ID : 81 Name : Zebra Information Server/GFS/YAZ Version: 2.0.59/5.9.0 5c3d5999d1588a3963435412af22ec993b22e391 Options: search present delSet triggerResourceCtrl scan sort extendedServices namedResultSets Elapsed: 0.002689 Z base biblios Z format xml Z elem zebra::facet::au:0:100 Z f @attrset Bib-1 @or @or @or @or @or @attr 1=36 @attr 4=1 @attr 6=3 @attr 9=32 @attr 2=102 mark twain @attr 1=4 @attr 4=1 @attr 6=3 @attr 9=28 @attr 2=102 mark twain @attr 1=36 @attr 4=1 @attr 9=26 @attr 2=102 mark twain @attr 1=4 @attr 4=6 @attr 9=24 @attr 2=102 mark twain @attr 4=6 @attr 5=1 @attr 9=14 @attr 2=102 mark? twain? @attr 4=6 @attr 9=14 @attr 2=102 mark twain Sent searchRequest. Received SearchResponse. Search was a success. Number of hits: 456, setno 1 SearchResult-1: term=mark twain cnt=16, term=mark twain cnt=16, term=mark cnt=215, term=twain cnt=97, term=mark cnt=2018, term=twain cnt=374, term=mark cnt=5366, term=twain cnt=480, term=mark cnt=3033, term=twain cnt=478 records returned: 0 Elapsed: 0.020487 Z s 1+1 Sent presentRequest (1+1). Records: 1 Diagnostic message(s) from database: [25] Specified element set name not valid for specified database -- v2 addinfo '' nextResultSetPosition = 2 Elapsed: 0.000495 Z --- Cindy Murdock Ames IT Services Director Meadville Public Library | CCFLS http://meadvillelibrary.org | http://ccfls.org Please report tech support issues in Mantis: http://tracker.ccfls.org/mantis On Tue, Feb 3, 2015 at 11:07 AM, Cindy Murdock Ames cmurd...@ccfls.org wrote: Thanks Tomas and Kyle for the clarification, sorry for the misinterpretation. Here's the output from zebra when I start it manually and do a search in the catalog: 11:00:43-03/02 zebrasrv(3) [session] Session - OK 3 unix:/home/kohaclone/koha-dev/var/run/zebradb/bibliosocket PID=23191 11:00:43-03/02 zebrasrv(3) [request] Auth idPass kohaclone - 11:00:43-03/02 zebrasrv(3) [request] Init OK - ID:81 Name:ZOOM-C/YAZ Version:5.9.0 5c3d5999d1588a3963435412af22ec993b22e391 11:00:43-03/02 zebrasrv(3) [log] dict_lookup_grep: (\x01\x1C)(m(a|\xC3\xA1|\xC3\xA0|\xC3\xA3|\xC3\xA5|\xC3\xA2|\xC4\x83|\xC4\x85|\xC8\xA7|\xC7\x8E|\xC8\x81|\xC8\x83)rk\ tw(a|\xC3\xA1|\xC3\xA0|\xC3\xA3|\xC3\xA5|\xC3\xA2|\xC4\x83|\xC4\x85|\xC8\xA7|\xC7\x8E|\xC8\x81|\xC8\x83)(i|\xC3\xAD|\xC3\xAC|\xC3\xAE|\xE1\xBB\x8B|\xC4\xA9|\xC4\xAD|\xC4\xAF|\xC7\x90|\xC8\x89|\xC8\x8B)n) 11:00:43-03/02 zebrasrv(3) [log] dict_lookup_grep: (\x01 )(m(a|\xC3\xA1|\xC3\xA0|\xC3\xA3|\xC3\xA5|\xC3\xA2|\xC4\x83|\xC4\x85|\xC8\xA7|\xC7\x8E|\xC8\x81|\xC8\x83)rk\ tw(a|\xC3\xA1|\xC3\xA0|\xC3\xA3|\xC3\xA5|\xC3\xA2|\xC4\x83|\xC4\x85|\xC8\xA7|\xC7\x8E|\xC8\x81|\xC8\x83)(i|\xC3\xAD|\xC3\xAC|\xC3\xAE|\xE1\xBB\x8B|\xC4\xA9|\xC4\xAD|\xC4\xAF|\xC7\x90|\xC8\x89|\xC8\x8B)n) 11:00:43-03/02 zebrasrv(3) [log] dict_lookup_grep: (\x01\x1A)(m(a|\xC3\xA1|\xC3\xA0|\xC3\xA3|\xC3\xA5|\xC3\xA2|\xC4\x83|\xC4\x85|\xC8\xA7|\xC7\x8E|\xC8\x81|\xC8\x83)rk) 11:00:43-03/02 zebrasrv(3) [log] dict_lookup_grep: (\x01\x1A)(tw(a|\xC3\xA1|\xC3\xA0|\xC3\xA3|\xC3\xA5|\xC3\xA2|\xC4\x83|\xC4\x85|\xC8\xA7|\xC7\x8E|\xC8\x81|\xC8\x83)(i|\xC3\xAD|\xC3\xAC|\xC3\xAE|\xE1\xBB\x8B|\xC4\xA9|\xC4\xAD|\xC4\xAF|\xC7\x90|\xC8\x89|\xC8\x8B)n) 11:00:43-03/02 zebrasrv(3) [log] dict_lookup_grep: (\x01\x1E)(m(a|\xC3\xA1|\xC3\xA0|\xC3\xA3|\xC3\xA5|\xC3\xA2|\xC4\x83|\xC4\x85|\xC8\xA7|\xC7\x8E|\xC8\x81|\xC8\x83)rk) 11:00:43-03/02 zebrasrv(3) [log] dict_lookup_grep: (\x01\x1E)(tw(a|\xC3\xA1|\xC3\xA0|\xC3\xA3|\xC3\xA5|\xC3\xA2|\xC4\x83|\xC4\x85|\xC8\xA7|\xC7\x8E|\xC8\x81|\xC8\x83)(i|\xC3\xAD|\xC3\xAC|\xC3\xAE|\xE1\xBB\x8B|\xC4\xA9|\xC4\xAD|\xC4\xAF|\xC7\x90|\xC8\x89|\xC8\x8B)n) 11:00:43-03/02 zebrasrv(3) [log] dict_lookup_grep: (\x01l\x01\x02)(m(a|\xC3\xA1|\xC3\xA0|\xC3\xA3|\xC3\xA5|\xC3\xA2|\xC4\x83|\xC4\x85|\xC8\xA7|\xC7\x8E|\xC8\x81|\xC8\x83)rk.*) 11:00:43-03/02 zebrasrv(3) [log] dict_lookup_grep: (\x01l\x01\x02)(tw(a|\xC3\xA1|\xC3\xA0|\xC3\xA3|\xC3\xA5|\xC3\xA2|\xC4\x83|\xC4\x85
[Koha] Fwd: Facets missing on fresh dev install of 3.18.3
Hi Michał, The opac isn't publicly accessible yet but here's a screenshot: http://i.imgur.com/0hdHrbm.png The area where the facets usually are is completely blank, even the Refine your search header is missing. We are using marc21, the xsl, xml record.abs files are present in my installation and the zebra configuration files look like they're pointing to them correctly. I haven't edited them at all. I do have logs from my last reindexing here: http://ccfls.org/files/reindex-output-1-28-15.txt. Regards, Cindy --- Cindy Murdock Ames IT Services Director Meadville Public Library | CCFLS http://meadvillelibrary.org | http://ccfls.org On Thu, Jan 29, 2015 at 2:28 AM, Michał Dudzik dudzikmic...@wp.pl wrote: Hi Cindy, All facets will not show? Show opac web adres to look about your problem. Index field facets you find in biblio-zebra-indexdefs.xsl, biblio-zebra-indexdefs.xml, record.abs (default if you use Marc21 - /etc/koha/zebradb/marc_defs/marc21/biblios). Declaration what facets show is in the file Koha.pm (default /usr/share/koha/lib/C4/). Regards Michał Dudzik -- View this message in context: http://koha.1045719.n5.nabble.com/Facets-missing-on-fresh-dev-install-of-3-18-3-tp5826755p5826803.html Sent from the Koha-general mailing list archive at Nabble.com. ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
[Koha] Facets missing on fresh dev install of 3.18.3
Hi all, I'm working on setting up a new server with a fresh dev install of 3.18.3 (well, it was a fresh install of 3.18.2 last week but I've updated it) using a copy of our database from our current server, which is running a customized version of 3.01.133. I've run updatedatabase.pl on it (manually because otherwise apache times out) as well as remove_items_from_biblioitems.pl. Everything seems to work *except* for the search facets. I've done a lot of googling, and I suspect it has to do with the new zebra faceting system, but I don't know enough about zebra to figure out why this is happening, so I'd be grateful if someone could help me figure this out. Zebra appears to be working otherwise, I do get search results, just no facets. In other cases I found where people were having trouble their indexing was not working at all because it wasn't fully configured to use dom, but I chose to use dom from the installer and as far as I can tell from my koha-conf.xml it's configured correctly. Pertinent bits from koha-conf.xml: server id=biblioserver listenref=biblioserver directory/home/kohaclone/koha-dev/var/lib/zebradb/biblios/directory config/home/kohaclone/koha-dev/etc/zebradb/zebra-biblios-dom.cfg/config cql2rpn/home/kohaclone/koha-dev/etc/zebradb/pqf.properties/cql2rpn xi:include href=/home/kohaclone/koha-dev/etc/zebradb/retrieval-info-bib-dom.xml xmlns:xi=http://www.w3.org/2001/XInclude/ xi:include href=/home/kohaclone/koha-dev/etc/zebradb/explain-biblios.xml xmlns:xi= http://www.w3.org/2001/XInclude/ /server server id=authorityserver listenref=authorityserver directory/home/kohaclone/koha-dev/var/lib/zebradb/authorities/directory config/home/kohaclone/koha-dev/etc/zebradb/zebra-authorities-dom.cfg/config cql2rpn/home/kohaclone/koha-dev/etc/zebradb/pqf.properties/cql2rpn xi:include href=/home/kohaclone/koha-dev/etc/zebradb/retrieval-info-auth-dom.xml xmlns:xi=http://www.w3.org/2001/XInclude/ xi:include href=/home/kohaclone/koha-dev/etc/zebradb/explain-authorities.xml xmlns:xi=http://www.w3.org/2001/XInclude/ /server (Note--we don't use authorities so I haven't bothered to run rebuild_zebra.pl with -a) zebra_bib_index_modedom/zebra_bib_index_mode zebra_auth_index_modedom/zebra_auth_index_mode zebra_lockdir/home/kohaclone/koha-dev/var/lock/zebradb/zebra_lockdir use_zebra_facets1/use_zebra_facets queryparser_config/home/kohaclone/koha-dev/etc/searchengine/queryparser.yaml/queryparser_config I've tried reindexing biblios with -x and without, doesn't seem to make any difference. I haven't done anything with any of the zebra config files, they are just as they were downloaded. The only anomaly I see in my logs is something like this every time I do a search, in koha-zebradaemon-output.log 12:55:54-28/01 zebrasrv(10) [warn] ir_session (exception) BTW this is running on Debian Wheezy. Thanks for reading, and thanks for any clue you can provide! Regards, Cindy --- Cindy Murdock Ames IT Services Director Meadville Public Library | CCFLS http://meadvillelibrary.org | http://ccfls.org ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Re: [Koha] [Koha North America] 2015 Koha North America User's Group - Proposed Sites
I'm thrilled that Mercyhurst submitted a proposal for Erie, PA. That is practically in my backyard! --- Cindy Murdock Ames IT Services Director Meadville Public Library | CCFLS http://meadvillelibrary.org | http://ccfls.org Please report tech support issues in Mantis: http://tracker.ccfls.org/mantis On Mon, Nov 17, 2014 at 5:31 PM, Jason Robb jr...@sekls.org wrote: Three contenders have thrown in to host the 2015 Koha North America User's Group Meeting. Each proposal has been posted to the Koha North America Wiki: http://koha-na.org/index.php/2015_Meeting_Site_Proposals Please take a moment to read through all three proposals. A survey will be sent later this week so you can vote for your favorite! Stay tuned to the KohaNA mailing list (sign up at http://lists.bywatersolutions.com/mailman/listinfo/kohana) for more information. Jason Robb SEKnFind Coordinator Southeast Kansas Library System jr...@sekls.org ___ KohaNa mailing list koh...@lists.bywatersolutions.com http://lists.bywatersolutions.com/mailman/listinfo/kohana ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Re: [Koha] Call for Manual Help
Hi Nicole, I'm working on docs for Rotating Collections! It's not in Tomas' list but it has passed QA so hopefully it will make into 3.18. Cindy --- Cindy Murdock Ames IT Services Director Meadville Public Library | CCFLS http://meadvillelibrary.org | http://ccfls.org ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
[Koha] mandatory default value ignored when adding items
Hi all, I just noticed yesterday on an install (from git, on debian squeeze) of 3.4 that when I add an item not only does it ignore the hidden property (bug 6439: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6439) but it also ignores the default values that I've set for some fields as well as the mandatory setting. Am I missing something in the configuration, is it a bug, or is it just me? Cheers! Cindy -- ~~ Cindy Murdock Ames IT Services Director Meadville Public Library| CCFLS http://meadvillelibrary.org | http://ccfls.org ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
