Hi all, Hope you all are pretty fine. Am trying to upgrade my Koha System version, from version 3.00.00.107 to version 3.00.05.003. As Web Installer tried to update database Am getting the following errors below; Update errors : * [Wed Jun 2 23:35:40 2010] updatedatabase.pl: DBD::mysql::db do failed: Duplicate entry 'AllowRenewalLimitOverride' for key 'PRIMARY' at /usr/share/koha/intranet/cgi-bin/installer/data/mysql/updatedatabase30.pl line 416. * [Wed Jun 2 23:35:40 2010] updatedatabase.pl: DBD::mysql::db do failed: Duplicate entry 'reserves-HOLD' for key 'PRIMARY' at /usr/share/koha/intranet/cgi-bin/installer/data/mysql/updatedatabase30.pl line 430. * [Wed Jun 2 23:35:40 2010] updatedatabase.pl: DBD::mysql::db do failed: Duplicate entry '4' for key 'PRIMARY' at /usr/share/koha/intranet/cgi-bin/installer/data/mysql/updatedatabase30.pl line 434. * [Wed Jun 2 23:35:40 2010] updatedatabase.pl: DBD::mysql::db do failed: Duplicate entry '4-sms-0' for key 'PRIMARY' at /usr/share/koha/intranet/cgi-bin/installer/data/mysql/updatedatabase30.pl line 435. * [Wed Jun 2 23:35:40 2010] updatedatabase.pl: DBD::mysql::db do failed: Duplicate entry '4-email-0' for key 'PRIMARY' at /usr/share/koha/intranet/cgi-bin/installer/data/mysql/updatedatabase30.pl line 436. * [Wed Jun 2 23:35:40 2010] updatedatabase.pl: DBD::mysql::db do failed: Duplicate key name 'issn' at /usr/share/koha/intranet/cgi-bin/installer/data/mysql/updatedatabase30.pl line 443. * [Wed Jun 2 23:35:40 2010] updatedatabase.pl: DBD::mysql::db do failed: Duplicate entry '1-override_renewals' for key 'PRIMARY' at /usr/share/koha/intranet/cgi-bin/installer/data/mysql/updatedatabase30.pl line 500. * [Wed Jun 2 23:35:41 2010] updatedatabase.pl: DBD::mysql::db do failed: Duplicate entry 'RenewalPeriodBase' for key 'PRIMARY' at /usr/share/koha/intranet/cgi-bin/installer/data/mysql/updatedatabase30.pl line 548. Continue to log in to Koha. What Should I do to fix these errors. Thanx for your cooperation, Regards, Bariki G. Kamara ---------------------- CONFIDENTIALITY NOTICE -------------------------------- PLEASE CONSIDER THE ENVIRONMENT BEFORE PRINTING THIS E-MAIL This email is intended only for the person to whom it is addressed and may contain confidential information and may be legally privileged. If you are not the intended recipient, you are notified that you may not use, distribute or copy this document in any manner whatsoever. Kindly also notify the sender by email and/or delete this e-mail. Any views or opinions expressed in this e-mail are those of the sender and do not necessarily coincide with those of the Open University of Tanzania. --------------------THE OPEN UNIVERSITY OF TANZANIA--------------------------
Hello, I get similar messages when upgrading from 3.00.02 to 3.00.05 though not as many as yours. I assume that those keys already exists and just ignore them. And so far my installation works ok. Olugbenga Adara Mobile: 234-803-3220288 --- On Thu, 6/3/10, bariki.kamara@out.ac.tz <bariki.kamara@out.ac.tz> wrote:
From: bariki.kamara@out.ac.tz <bariki.kamara@out.ac.tz> Subject: [Koha] Update errors To: koha@lists.katipo.co.nz Date: Thursday, June 3, 2010, 8:48 AM Hi all,
Hope you all are pretty fine.
Am trying to upgrade my Koha System version, from version 3.00.00.107 to version 3.00.05.003. As Web Installer tried to update database Am getting the following errors below;
Update errors :
* [Wed Jun 2 23:35:40 2010] updatedatabase.pl: DBD::mysql::db do failed: Duplicate entry 'AllowRenewalLimitOverride' for key 'PRIMARY' at /usr/share/koha/intranet/cgi-bin/installer/data/mysql/updatedatabase30.pl line 416.
* [Wed Jun 2 23:35:40 2010] updatedatabase.pl: DBD::mysql::db do failed: Duplicate entry 'reserves-HOLD' for key 'PRIMARY' at /usr/share/koha/intranet/cgi-bin/installer/data/mysql/updatedatabase30.pl line 430.
* [Wed Jun 2 23:35:40 2010] updatedatabase.pl: DBD::mysql::db do failed: Duplicate entry '4' for key 'PRIMARY' at /usr/share/koha/intranet/cgi-bin/installer/data/mysql/updatedatabase30.pl line 434.
* [Wed Jun 2 23:35:40 2010] updatedatabase.pl: DBD::mysql::db do failed: Duplicate entry '4-sms-0' for key 'PRIMARY' at /usr/share/koha/intranet/cgi-bin/installer/data/mysql/updatedatabase30.pl line 435.
* [Wed Jun 2 23:35:40 2010] updatedatabase.pl: DBD::mysql::db do failed: Duplicate entry '4-email-0' for key 'PRIMARY' at /usr/share/koha/intranet/cgi-bin/installer/data/mysql/updatedatabase30.pl line 436.
* [Wed Jun 2 23:35:40 2010] updatedatabase.pl: DBD::mysql::db do failed: Duplicate key name 'issn' at /usr/share/koha/intranet/cgi-bin/installer/data/mysql/updatedatabase30.pl line 443.
* [Wed Jun 2 23:35:40 2010] updatedatabase.pl: DBD::mysql::db do failed: Duplicate entry '1-override_renewals' for key 'PRIMARY' at /usr/share/koha/intranet/cgi-bin/installer/data/mysql/updatedatabase30.pl line 500.
* [Wed Jun 2 23:35:41 2010] updatedatabase.pl: DBD::mysql::db do failed: Duplicate entry 'RenewalPeriodBase' for key 'PRIMARY' at /usr/share/koha/intranet/cgi-bin/installer/data/mysql/updatedatabase30.pl line 548.
Continue to log in to Koha.
What Should I do to fix these errors. Thanx for your cooperation, Regards, Bariki G. Kamara
---------------------- CONFIDENTIALITY NOTICE --------------------------------
PLEASE CONSIDER THE ENVIRONMENT BEFORE PRINTING THIS E-MAIL
This email is intended only for the person to whom it is addressed and may contain confidential information and may be legally privileged. If you are not the intended recipient, you are notified that you may not use, distribute or copy this document in any manner whatsoever. Kindly also notify the sender by email and/or delete this e-mail. Any views or opinions expressed in this e-mail are those of the sender and do not necessarily coincide with those of the Open University of Tanzania.
--------------------THE OPEN UNIVERSITY OF TANZANIA--------------------------
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Hello, I get similar messages when upgrading from 3.00.02 to 3.00.05 though not as many as yours. I assume that those keys already exists and just ignore them. And so far my installation works ok. Olugbenga Adara Mobile: 234-803-3220288 --- On Thu, 6/3/10, bariki.kamara@out.ac.tz <bariki.kamara@out.ac.tz> wrote:
From: bariki.kamara@out.ac.tz <bariki.kamara@out.ac.tz> Subject: [Koha] Update errors To: koha@lists.katipo.co.nz Date: Thursday, June 3, 2010, 8:48 AM Hi all,
Hope you all are pretty fine.
Am trying to upgrade my Koha System version, from version 3.00.00.107 to version 3.00.05.003. As Web Installer tried to update database Am getting the following errors below;
Update errors :
* [Wed Jun 2 23:35:40 2010] updatedatabase.pl: DBD::mysql::db do failed: Duplicate entry 'AllowRenewalLimitOverride' for key 'PRIMARY' at /usr/share/koha/intranet/cgi-bin/installer/data/mysql/updatedatabase30.pl line 416.
* [Wed Jun 2 23:35:40 2010] updatedatabase.pl: DBD::mysql::db do failed: Duplicate entry 'reserves-HOLD' for key 'PRIMARY' at /usr/share/koha/intranet/cgi-bin/installer/data/mysql/updatedatabase30.pl line 430.
* [Wed Jun 2 23:35:40 2010] updatedatabase.pl: DBD::mysql::db do failed: Duplicate entry '4' for key 'PRIMARY' at /usr/share/koha/intranet/cgi-bin/installer/data/mysql/updatedatabase30.pl line 434.
* [Wed Jun 2 23:35:40 2010] updatedatabase.pl: DBD::mysql::db do failed: Duplicate entry '4-sms-0' for key 'PRIMARY' at /usr/share/koha/intranet/cgi-bin/installer/data/mysql/updatedatabase30.pl line 435.
* [Wed Jun 2 23:35:40 2010] updatedatabase.pl: DBD::mysql::db do failed: Duplicate entry '4-email-0' for key 'PRIMARY' at /usr/share/koha/intranet/cgi-bin/installer/data/mysql/updatedatabase30.pl line 436.
* [Wed Jun 2 23:35:40 2010] updatedatabase.pl: DBD::mysql::db do failed: Duplicate key name 'issn' at /usr/share/koha/intranet/cgi-bin/installer/data/mysql/updatedatabase30.pl line 443.
* [Wed Jun 2 23:35:40 2010] updatedatabase.pl: DBD::mysql::db do failed: Duplicate entry '1-override_renewals' for key 'PRIMARY' at /usr/share/koha/intranet/cgi-bin/installer/data/mysql/updatedatabase30.pl line 500.
* [Wed Jun 2 23:35:41 2010] updatedatabase.pl: DBD::mysql::db do failed: Duplicate entry 'RenewalPeriodBase' for key 'PRIMARY' at /usr/share/koha/intranet/cgi-bin/installer/data/mysql/updatedatabase30.pl line 548.
Continue to log in to Koha.
What Should I do to fix these errors. Thanx for your cooperation, Regards, Bariki G. Kamara
---------------------- CONFIDENTIALITY NOTICE --------------------------------
PLEASE CONSIDER THE ENVIRONMENT BEFORE PRINTING THIS E-MAIL
This email is intended only for the person to whom it is addressed and may contain confidential information and may be legally privileged. If you are not the intended recipient, you are notified that you may not use, distribute or copy this document in any manner whatsoever. Kindly also notify the sender by email and/or delete this e-mail. Any views or opinions expressed in this e-mail are those of the sender and do not necessarily coincide with those of the Open University of Tanzania.
--------------------THE OPEN UNIVERSITY OF TANZANIA--------------------------
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Good Morning, I am having problems with Koha returning the following error: Koha error The following fatal error has occurred: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) at /usr/share/perl/5.8/CGI/Carp.pm line 314. Compilation failed in require at /usr/share/koha/lib/C4/Auth.pm line 30. BEGIN failed--compilation aborted at /usr/share/koha/lib/C4/Auth.pm line 30. Compilation failed in require at /usr/share/koha/opac/cgi-bin/opac/opac-detail.pl line 25. BEGIN failed--compilation aborted at /usr/share/koha/opac/cgi-bin/opac/opac-detail.pl line 25. If I refresh the page it usually works, but this error appears more often than not since yesterday morning. I looked at some performance items suspecting that it may be related to slow response from the underlying system. top - 08:31:07 up 20:01, 1 user, load average: 0.21, 0.24, 0.25 # for i in a b; do hdparm -tT /dev/sd"$i"; done /dev/sda: Timing cached reads: 2166 MB in 1.88 seconds = 1152.66 MB/sec Timing buffered disk reads: 22 MB in 3.28 seconds = 6.71 MB/sec /dev/sdb: Timing cached reads: 2530 MB in 1.87 seconds = 1355.50 MB/sec Timing buffered disk reads: 34 MB in 3.32 seconds = 10.24 MB/sec # mount /dev/sda1 on / type ext3 (rw,relatime,errors=remount-ro) proc on /proc type proc (rw,noexec,nosuid,nodev) /sys on /sys type sysfs (rw,noexec,nosuid,nodev) varrun on /var/run type tmpfs (rw,noexec,nosuid,nodev,mode=0755) varlock on /var/lock type tmpfs (rw,noexec,nosuid,nodev,mode=1777) udev on /dev type tmpfs (rw,mode=0755) devshm on /dev/shm type tmpfs (rw) devpts on /dev/pts type devpts (rw,gid=5,mode=620) /dev/sdb1 on /var/lib type ext3 (rw,relatime,errors=remount-ro) It looks to me like the drives are slow. Not all that surprising considering that there are 6 virtual machines running off the same hyper-V host. What can I do to increase the performance under these conditions, or am I on the wrong track entirely? Best regards, Robert Meltz
Consider using the IP address (127.0.0.1) instead of localhost for the db connection. This will cause mysql to connect via TCP instead of using a named socket and may help -- assuming your database is responsive otherwise. ( Mysql's decision to trap the localhost name and act differently with it instead of making that a separate option is insane but in character. ) -reed On Sat, Jun 5, 2010 at 12:35 AM, Robert Meltz <RMeltz@insolnet.com> wrote:
Good Morning,
I am having problems with Koha returning the following error:
Koha error The following fatal error has occurred:
Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) at /usr/share/perl/5.8/CGI/Carp.pm line 314. Compilation failed in require at /usr/share/koha/lib/C4/Auth.pm line 30. BEGIN failed--compilation aborted at /usr/share/koha/lib/C4/Auth.pm line 30. Compilation failed in require at /usr/share/koha/opac/cgi-bin/opac/opac-detail.pl line 25. BEGIN failed--compilation aborted at /usr/share/koha/opac/cgi-bin/opac/opac-detail.pl line 25.
If I refresh the page it usually works, but this error appears more often than not since yesterday morning. I looked at some performance items suspecting that it may be related to slow response from the underlying system.
top - 08:31:07 up 20:01, 1 user, load average: 0.21, 0.24, 0.25
# for i in a b; do hdparm -tT /dev/sd"$i"; done
/dev/sda: Timing cached reads: 2166 MB in 1.88 seconds = 1152.66 MB/sec Timing buffered disk reads: 22 MB in 3.28 seconds = 6.71 MB/sec
/dev/sdb: Timing cached reads: 2530 MB in 1.87 seconds = 1355.50 MB/sec Timing buffered disk reads: 34 MB in 3.32 seconds = 10.24 MB/sec
# mount /dev/sda1 on / type ext3 (rw,relatime,errors=remount-ro) proc on /proc type proc (rw,noexec,nosuid,nodev) /sys on /sys type sysfs (rw,noexec,nosuid,nodev) varrun on /var/run type tmpfs (rw,noexec,nosuid,nodev,mode=0755) varlock on /var/lock type tmpfs (rw,noexec,nosuid,nodev,mode=1777) udev on /dev type tmpfs (rw,mode=0755) devshm on /dev/shm type tmpfs (rw) devpts on /dev/pts type devpts (rw,gid=5,mode=620) /dev/sdb1 on /var/lib type ext3 (rw,relatime,errors=remount-ro)
It looks to me like the drives are slow. Not all that surprising considering that there are 6 virtual machines running off the same hyper-V host. What can I do to increase the performance under these conditions, or am I on the wrong track entirely?
Best regards, Robert Meltz _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Thanks Reed, could you please clarify a bit? Are you referring to the line in my.cnf that contains "bind-address" because if so, it is already set to 127.0.0.1. Best regards, Robert Meltz Field Service Engineer 770.458.8658 x108 404.642.9093 cell rmeltz@insolnet.com www.insolnet.com Follow us on Twitter: www.twitter.com/Insol_IT At Insol: ownership and partnership know no bounds. IT's personal. -----Original Message----- From: reedwade@gmail.com [mailto:reedwade@gmail.com] On Behalf Of Reed Wade Sent: Friday, June 04, 2010 10:48 PM To: Robert Meltz Cc: koha@lists.katipo.co.nz Subject: Re: [Koha] MySQL socket errors Consider using the IP address (127.0.0.1) instead of localhost for the db connection. This will cause mysql to connect via TCP instead of using a named socket and may help -- assuming your database is responsive otherwise. ( Mysql's decision to trap the localhost name and act differently with it instead of making that a separate option is insane but in character. ) -reed On Sat, Jun 5, 2010 at 12:35 AM, Robert Meltz <RMeltz@insolnet.com> wrote:
Good Morning,
I am having problems with Koha returning the following error:
Koha error The following fatal error has occurred:
Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) at /usr/share/perl/5.8/CGI/Carp.pm line 314. Compilation failed in require at /usr/share/koha/lib/C4/Auth.pm line 30. BEGIN failed--compilation aborted at /usr/share/koha/lib/C4/Auth.pm line 30. Compilation failed in require at /usr/share/koha/opac/cgi-bin/opac/opac-detail.pl line 25. BEGIN failed--compilation aborted at /usr/share/koha/opac/cgi-bin/opac/opac-detail.pl line 25.
If I refresh the page it usually works, but this error appears more often than not since yesterday morning. I looked at some performance items suspecting that it may be related to slow response from the underlying system.
top - 08:31:07 up 20:01, 1 user, load average: 0.21, 0.24, 0.25
# for i in a b; do hdparm -tT /dev/sd"$i"; done
/dev/sda: Timing cached reads: 2166 MB in 1.88 seconds = 1152.66 MB/sec Timing buffered disk reads: 22 MB in 3.28 seconds = 6.71 MB/sec
/dev/sdb: Timing cached reads: 2530 MB in 1.87 seconds = 1355.50 MB/sec Timing buffered disk reads: 34 MB in 3.32 seconds = 10.24 MB/sec
# mount /dev/sda1 on / type ext3 (rw,relatime,errors=remount-ro) proc on /proc type proc (rw,noexec,nosuid,nodev) /sys on /sys type sysfs (rw,noexec,nosuid,nodev) varrun on /var/run type tmpfs (rw,noexec,nosuid,nodev,mode=0755) varlock on /var/lock type tmpfs (rw,noexec,nosuid,nodev,mode=1777) udev on /dev type tmpfs (rw,mode=0755) devshm on /dev/shm type tmpfs (rw) devpts on /dev/pts type devpts (rw,gid=5,mode=620) /dev/sdb1 on /var/lib type ext3 (rw,relatime,errors=remount-ro)
It looks to me like the drives are slow. Not all that surprising considering that there are 6 virtual machines running off the same hyper-V host. What can I do to increase the performance under these conditions, or am I on the wrong track entirely?
Best regards, Robert Meltz _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
I looked at /var/log/syslog and found that my problem is worse than it seemed: Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: InnoDB: Dump of the tablespace extent descriptor: len 40; hex 00000000000006e40000400008e60000400002f600000001ffffffffffffffffffffffffffffffff; asc @ @ ; Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: InnoDB: Serious error! InnoDB is trying to free page 17131 Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: InnoDB: though it is already marked as free in the tablespace! Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: InnoDB: The tablespace free space info is corrupt. Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: InnoDB: You may need to dump your InnoDB tables and recreate the whole Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: InnoDB: database! Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: InnoDB: Please refer to Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: InnoDB: about forcing recovery. Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: 100607 9:41:28InnoDB: Assertion failure in thread 2982538128 in file fsp0fsp.c line 2981 Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: InnoDB: We intentionally generate a memory trap. Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: InnoDB: Submit a detailed bug report to http://bugs.mysql.com. Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: InnoDB: If you get repeated assertion failures or crashes, even Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: InnoDB: immediately after the mysqld startup, there may be Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: InnoDB: corruption in the InnoDB tablespace. Please refer to Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: InnoDB: about forcing recovery. Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: 100607 9:41:28 - mysqld got signal 11; Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: This could be because you hit a bug. It is also possible that this binary Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: or one of the libraries it was linked against is corrupt, improperly built, Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: or misconfigured. This error can also be caused by malfunctioning hardware. Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: We will try our best to scrape up some info that will hopefully help diagnose Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: the problem, but since we have already crashed, something is definitely wrong Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: and this may fail. Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: key_buffer_size=16777216 Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: read_buffer_size=131072 Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: max_used_connections=2 Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: max_connections=100 Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: threads_connected=1 Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: It is possible that mysqld could use up to Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 233983 K Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: bytes of memory Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: Hope that's ok; if not, decrease some variables in the equation. Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: thd=(nil) Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: Attempting backtrace. You can use the following information to find out Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: where mysqld died. If you see no messages after this, something went Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: terribly wrong... Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: Cannot determine thread, fp=0xb1c5cf48, backtrace may not be correct. Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: Stack range sanity check OK, backtrace follows: Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: 0x81cd88d Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: 0x83cdf5c Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: 0x83664c5 Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: 0x836676c Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: 0x836c957 Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: 0x837660e Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: 0x837865e Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: 0x83466ce Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: 0x8347ac7 Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: 0x832ab97 Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: 0x838a6e9 Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: 0x830df1c Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: 0xb76d84fb Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: 0xb74ecf5e Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: New value of fp=(nil) failed sanity check, terminating stack trace! Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: Please read http://dev.mysql.com/doc/mysql/en/using-stack-trace.html and follow instructions on how to resolve the stack trace. Resolved Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: stack trace is much more helpful in diagnosing the problem, so please do Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: resolve it Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: The manual page at http://www.mysql.com/doc/en/Crashing.html contains Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: information that should help you find out what is causing the crash. Jun 7 09:41:28 lru-lnx-srv02 Koha Zebraqueue [31497]: failed to connect to DB: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (111) Jun 7 09:41:28 lru-lnx-srv02 mysqld_safe[27083]: Number of processes running now: 0 Jun 7 09:41:28 lru-lnx-srv02 mysqld_safe[27085]: restarted Jun 7 09:41:28 lru-lnx-srv02 mysqld[27088]: InnoDB: Log scan progressed past the checkpoint lsn 1 1833585166 Jun 7 09:41:28 lru-lnx-srv02 mysqld[27088]: 100607 9:41:28 InnoDB: Database was not shut down normally! Jun 7 09:41:28 lru-lnx-srv02 mysqld[27088]: InnoDB: Starting crash recovery. Jun 7 09:41:28 lru-lnx-srv02 mysqld[27088]: InnoDB: Reading tablespace information from the .ibd files... Jun 7 09:41:28 lru-lnx-srv02 mysqld[27088]: InnoDB: Restoring possible half-written data pages from the doublewrite Jun 7 09:41:28 lru-lnx-srv02 mysqld[27088]: InnoDB: buffer... Jun 7 09:41:28 lru-lnx-srv02 mysqld[27088]: InnoDB: Doing recovery: scanned up to log sequence number 1 1833662694 Jun 7 09:41:28 lru-lnx-srv02 mysqld[27088]: 100607 9:41:28 InnoDB: Starting an apply batch of log records to the database... Jun 7 09:41:28 lru-lnx-srv02 mysqld[27088]: InnoDB: Progress in percents: 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 Jun 7 09:41:28 lru-lnx-srv02 mysqld[27088]: InnoDB: Apply batch completed Jun 7 09:41:28 lru-lnx-srv02 mysqld[27088]: 100607 9:41:28 InnoDB: Started; log sequence number 1 1833662694 Jun 7 09:41:28 lru-lnx-srv02 mysqld[27088]: 100607 9:41:28 [Note] /usr/sbin/mysqld: ready for connections. Jun 7 09:41:28 lru-lnx-srv02 mysqld[27088]: Version: '5.0.51a-24+lenny1~bpo40+1' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (Debian) Best regards, Robert Meltz Field Service Engineer 770.458.8658 x108 404.642.9093 cell rmeltz@insolnet.com www.insolnet.com Follow us on Twitter: www.twitter.com/Insol_IT At Insol: ownership and partnership know no bounds. IT's personal. -----Original Message----- From: koha-bounces@lists.katipo.co.nz [mailto:koha-bounces@lists.katipo.co.nz] On Behalf Of Robert Meltz Sent: Monday, June 07, 2010 8:56 AM To: Reed Wade Cc: koha@lists.katipo.co.nz Subject: Re: [Koha] MySQL socket errors Thanks Reed, could you please clarify a bit? Are you referring to the line in my.cnf that contains "bind-address" because if so, it is already set to 127.0.0.1. Best regards, Robert Meltz Field Service Engineer 770.458.8658 x108 404.642.9093 cell rmeltz@insolnet.com www.insolnet.com Follow us on Twitter: www.twitter.com/Insol_IT At Insol: ownership and partnership know no bounds. IT's personal. -----Original Message----- From: reedwade@gmail.com [mailto:reedwade@gmail.com] On Behalf Of Reed Wade Sent: Friday, June 04, 2010 10:48 PM To: Robert Meltz Cc: koha@lists.katipo.co.nz Subject: Re: [Koha] MySQL socket errors Consider using the IP address (127.0.0.1) instead of localhost for the db connection. This will cause mysql to connect via TCP instead of using a named socket and may help -- assuming your database is responsive otherwise. ( Mysql's decision to trap the localhost name and act differently with it instead of making that a separate option is insane but in character. ) -reed On Sat, Jun 5, 2010 at 12:35 AM, Robert Meltz <RMeltz@insolnet.com> wrote:
Good Morning,
I am having problems with Koha returning the following error:
Koha error The following fatal error has occurred:
Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) at /usr/share/perl/5.8/CGI/Carp.pm line 314. Compilation failed in require at /usr/share/koha/lib/C4/Auth.pm line 30. BEGIN failed--compilation aborted at /usr/share/koha/lib/C4/Auth.pm line 30. Compilation failed in require at /usr/share/koha/opac/cgi-bin/opac/opac-detail.pl line 25. BEGIN failed--compilation aborted at /usr/share/koha/opac/cgi-bin/opac/opac-detail.pl line 25.
If I refresh the page it usually works, but this error appears more often than not since yesterday morning. I looked at some performance items suspecting that it may be related to slow response from the underlying system.
top - 08:31:07 up 20:01, 1 user, load average: 0.21, 0.24, 0.25
# for i in a b; do hdparm -tT /dev/sd"$i"; done
/dev/sda: Timing cached reads: 2166 MB in 1.88 seconds = 1152.66 MB/sec Timing buffered disk reads: 22 MB in 3.28 seconds = 6.71 MB/sec
/dev/sdb: Timing cached reads: 2530 MB in 1.87 seconds = 1355.50 MB/sec Timing buffered disk reads: 34 MB in 3.32 seconds = 10.24 MB/sec
# mount /dev/sda1 on / type ext3 (rw,relatime,errors=remount-ro) proc on /proc type proc (rw,noexec,nosuid,nodev) /sys on /sys type sysfs (rw,noexec,nosuid,nodev) varrun on /var/run type tmpfs (rw,noexec,nosuid,nodev,mode=0755) varlock on /var/lock type tmpfs (rw,noexec,nosuid,nodev,mode=1777) udev on /dev type tmpfs (rw,mode=0755) devshm on /dev/shm type tmpfs (rw) devpts on /dev/pts type devpts (rw,gid=5,mode=620) /dev/sdb1 on /var/lib type ext3 (rw,relatime,errors=remount-ro)
It looks to me like the drives are slow. Not all that surprising considering that there are 6 virtual machines running off the same hyper-V host. What can I do to increase the performance under these conditions, or am I on the wrong track entirely?
Best regards, Robert Meltz _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
On Tue, Jun 8, 2010 at 12:55 AM, Robert Meltz <RMeltz@insolnet.com> wrote:
Thanks Reed, could you please clarify a bit? Are you referring to the line in my.cnf that contains "bind-address" because if so, it is already set to 127.0.0.1.
(Sounds like you find your real problem in that log, but..) No, in the client connection setting for koha. And my knowledge starts to get a little hazy at this point but I think the mysql service will create a named socket as well as listening on a TCP port. Client connection libraries will use the named socket if you use localhost as the host name instead of using the TCP connection. And 5-10 years ago that made a lot of sense, and maybe there still is some efficiency but I just hate it when apps try to be that cute (by this I mean treating localhost as a special name). With some virtual machine configurations local networking can be a little bit broken. -reed
participants (4)
-
bariki.kamara＠out.ac.tz -
Olugbenga Adara -
Reed Wade -
Robert Meltz