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 9999-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. 9999-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 9999-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.9999" this is accepted WITHOUT ERROR. (the local Koha system preference "datetime" is set to "dd.mm.yyyy") 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/9999" - 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 "9999-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 9999-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 mik@adminkuhn.ch · W www.adminkuhn.ch