Re: [Koha] Slow Koha OPAC login process - a bug? Workaround exists

[Jonathan Druart]

I still do not recreate the problem.

^ dates are handled in our Koha::DateUtils module, take a look at:

223 # FIXME: see bug 13242 => no TZ for dates 'infinite'
224 if ( $dt->ymd !~ /^/ )
{
225 my $tz = $dateonly ? DateTime::TimeZone->new(name =>
'floating') : C4::Context->tz;
226 $dt->set_time_zone( $tz
);
227 }

Well there is a fixme, but basically it says that if the date is from 
we should use floating dates to avoid long processing when comparing dates.

Take a look at 12669, 13242 and
https://metacpan.org/pod/DateTime#Determining-the-Local-Time-Zone-Can-Be-Slow

I guess there is a use of DateTime using the tz somewhere in the code.

On Thu, 18 May 2017 at 17:22 Michael Kuhn  wrote:

> Hi
>
> We're running a new host with Debian GNU/Linux 8 and Koha 16.11.04.
>
> On 13 April I first wrote that sometimea when trying to login into the
> Koha OPAC it takes more than 30 seconds until the login process finally
> comes to an end, while the process "opac-user.pl" was eating up 99% of
> the CPU.
>
> Some of you have kindly given my some hints but everything I tried was
> of no avail: logging mySQL slow queries, iotop, strace -c -p PID,
> tcpdump, checking logs (plack-error.log, opac-error.log etc etc),
> executing various time measurements of the Perl scripts, deactivating
> other programs (like Plack, EZproxy etc), enabling debugging for Plack,
> etc etc
>
> Eventually I executed "strace -t -s 1024 -p PID" and tried to understand
> the output. I doubt I did but some lines gave me the idea the problem
> was connected with the card expiry date. The user data were migrated
> from another ILS which contained a card expiry date of -12-31 for
> every user - I manually changed this to 2030-12-31 via SQL and all of a
> sudden the login process was quick as experienced elsewhere. So the
> problem feels like SOLVED by a workaround, at least in our Koha instance!
>
> But meanwhile we have found out the following:
>
> 1. -12-31 is a valid date accepted by MySQL (see
> https://dev.mysql.com/doc/refman/5.5/en/datetime.html)
>
> 2. The newly configured patron categories in our Koha instance all have
> an enrollment period of 999 months (strangely it's not possible to
> choose a higher number).
>
> 3. The migrated user data was imported via Koha menu "Tools > Patrons
> and circulation > Import patrons". NO ERROR occurred and all the data
> (including the date -12-31) was correctly written into table
> "borrowers".
>
> 4. In Koha menu "Patrons > New patron" when a new patron is added with
> expiry date "31.12." this is accepted WITHOUT ERROR. (the local Koha
> system preference "datetime" is set to "dd.mm.")
>
> 5. Trying to login into the Koha OPAC will immediately lead to described
> problem with the delayed login.
>
> 6. I tried step 4 on my own demo installation of Koha 16.11.00 with
> expiry date "31/12/" - there a dialogue appears saying "Invalid year
> entered in field dateexpiry". There is only a button "OK" - I clicked
> that and then saved the user data. This worked without further errors
> and the date can be found in field "borrowers.dateexpiry" as
> "-12-31". It seems rather strange to me that Koha should warn about
> an "invalid year" (whatever that means) but accepting it nonetheless.
> Trying to login with this user in the OPAC of my demo installation works
> quick as expected.
>
> To me the behavior (described in steps 1-5) feels like a bug because if
> date -12-31 is accepted by the patron import tool and also by MySQL
> then it shouldn't be necessary to change that date. (But it seems this
> problem is only existing on our Koha instance)
>
> Also the behavior (described in step 6) feels at least like a minor bug
> because if Koha warns of an "invalid year" it should 1) be more explicit
> (what exactly is invalid about the year?) and especially it shouldn't
> allow to save that "invalid" year.
>
> What do you think of this?
>
> Best wishes: Michael
> --
> Geschäftsführer · Diplombibliothekar BBS, Informatiker eidg. Fachausweis
> Admin Kuhn GmbH · Pappelstrasse 20 · 4123 Allschwil · Schweiz
> T 0041 (0)61 261 55 61 <+41%2061%20261%2055%2061> · E m...@adminkuhn.ch ·
> W www.adminkuhn.ch
> ___
> 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] Slow Koha OPAC login process - a bug? Workaround exists

[Michael Kuhn]

Hi

We're running a new host with Debian GNU/Linux 8 and Koha 16.11.04.

On 13 April I first wrote that sometimea when trying to login into the 
Koha OPAC it takes more than 30 seconds until the login process finally 
comes to an end, while the process "opac-user.pl" was eating up 99% of 
the CPU.


Some of you have kindly given my some hints but everything I tried was 
of no avail: logging mySQL slow queries, iotop, strace -c -p PID, 
tcpdump, checking logs (plack-error.log, opac-error.log etc etc), 
executing various time measurements of the Perl scripts, deactivating 
other programs (like Plack, EZproxy etc), enabling debugging for Plack, 
etc etc


Eventually I executed "strace -t -s 1024 -p PID" and tried to understand 
the output. I doubt I did but some lines gave me the idea the problem 
was connected with the card expiry date. The user data were migrated 
from another ILS which contained a card expiry date of -12-31 for 
every user - I manually changed this to 2030-12-31 via SQL and all of a 
sudden the login process was quick as experienced elsewhere. So the 
problem feels like SOLVED by a workaround, at least in our Koha instance!


But meanwhile we have found out the following:

1. -12-31 is a valid date accepted by MySQL (see 
https://dev.mysql.com/doc/refman/5.5/en/datetime.html)


2. The newly configured patron categories in our Koha instance all have 
an enrollment period of 999 months (strangely it's not possible to 
choose a higher number).


3. The migrated user data was imported via Koha menu "Tools > Patrons 
and circulation > Import patrons". NO ERROR occurred and all the data 
(including the date -12-31) was correctly written into table 
"borrowers".


4. In Koha menu "Patrons > New patron" when a new patron is added with 
expiry date "31.12." this is accepted WITHOUT ERROR. (the local Koha 
system preference "datetime" is set to "dd.mm.")


5. Trying to login into the Koha OPAC will immediately lead to described 
problem with the delayed login.


6. I tried step 4 on my own demo installation of Koha 16.11.00 with 
expiry date "31/12/" - there a dialogue appears saying "Invalid year 
entered in field dateexpiry". There is only a button "OK" - I clicked 
that and then saved the user data. This worked without further errors 
and the date can be found in field "borrowers.dateexpiry" as 
"-12-31". It seems rather strange to me that Koha should warn about 
an "invalid year" (whatever that means) but accepting it nonetheless. 
Trying to login with this user in the OPAC of my demo installation works 
quick as expected.


To me the behavior (described in steps 1-5) feels like a bug because if 
date -12-31 is accepted by the patron import tool and also by MySQL 
then it shouldn't be necessary to change that date. (But it seems this 
problem is only existing on our Koha instance)


Also the behavior (described in step 6) feels at least like a minor bug 
because if Koha warns of an "invalid year" it should 1) be more explicit 
(what exactly is invalid about the year?) and especially it shouldn't 
allow to save that "invalid" year.


What do you think of this?

Best wishes: Michael
--
Geschäftsführer · Diplombibliothekar BBS, Informatiker eidg. Fachausweis
Admin Kuhn GmbH · Pappelstrasse 20 · 4123 Allschwil · Schweiz
T 0041 (0)61 261 55 61 · E m...@adminkuhn.ch · W www.adminkuhn.ch
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Error uploading cover images

[Owen Leonard]

> MySQL server has gone away

I think this is the relevant part of that error message. MySQL stopped
working for some reason. With any luck restarting it will correct your
problem.

  -- Owen

-- 
Web Developer
Athens County Public Libraries
http://www.myacpl.org
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

[Koha] smtp: Failed: Server does not advertise any supported authentication methods

[Vimal Kumar V.]

Dear Friends,

I was trying to configure nullmailer with gmail using following document,

http://blog.janjonas.net/2011-04-22/configure-nullmailer-smtp-authentication/comment-page-1#comment-72420

Here is the format of login credentials in /etc/nullmailer/remotes

smtp.gmail.com smtp --port=587 --user=xyz --pass=xyz

Message did not sent, following is the error log of nullmailer,

May 18 14:33:54 koha nullmailer[13567]: smtp: Failed: Server does not
advertise any supported authentication methods
May 18 14:33:54 koha nullmailer[13409]: Sending failed:  Temporary error in
sending the message

Any clue regarding this error?

My Koha version  is 16.11.7

Regards,

-- 
Vimal Kumar V.
Librarian
School of Indian Legal Thought
Mahatma Gandhi University
Kottayam, Kerala
Web: http://www.vimalkumar.info
Blogs: http://linuxhalwa.blogspot.com http://kohageek.blogspot.in
http://dspacegeek.blogspot.in
http://moovandan.blogspot.in  
---
"I forget what I was taught. I only remember what I have learnt"
-Patrick White
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha