Re: [vchkpw] Spotty behavior authenticating: MySQL server has gone away
Dallas L. Engelken wrote: -Original Message- From: ISP Lists [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 24, 2005 10:21 AM To: vchkpw@inter7.com Subject: Re: [vchkpw] Spotty behavior authenticating: MySQL server has gone away Something peculiar happened to mysql during a reboot and now vpopmail authdaemond is having trouble completing authentications /var/log/maillog says: Aug 24 08:36:15 hostname authdaemond: vmysql: sql error[3]: MySQL server has gone away This problem is spotty though. I have several successful authentications before this error occurs. I then have to restart mysqld before I can get any other authentications to succeed. I am still able to use the mysql client to connect to the server for an interactive session. What seems strange to me is that there are only two mysql daemons running: root 23923 0.0 0.1 5060 1108 pts/0S09:13 0:00 /bin/sh /usr/bin/safe_mysqld --defaults-file=/etc/my.cnf --pid-file=/var/run/mysqld/mysqld.pid mysql23956 0.0 0.5 38620 5656 pts/0Sl 09:13 0:00 /usr/libexec/mysqld --defaults-file=/etc/my.cnf --basedir=/var/lib --datadir=/var/lib/mysql --user=mysql --pid-file=/var/run/mysqld/mysqld.pid --skip-locking Every other instance of mysql 3.23.x I've ever run has about 10 child threads running, so this seems strange to see only one child thread. I have not updated any packages on this box recently. None at all, I swear. Suggestions to investigate? Googling on the MySQL server has gone away is a wild goose chase. Hrm, rebooting the box seems to have helped. Still same number of mysql daemons, but they're answering now... Damned strange. dmesg on reboot didn't show any ext3 errors being fixed - I was wondering if this was a disk thing. Thoughts still welcome and appreciated on this. Well.. just for reference (cause it took me a while to figure this one out)... if your box is running with multiple name servers configured for resolution, and the primary stops responding, you will see this same issue. What happens is the slight delay added to the auth sequence as the mysql fails to the secondary resolver causes the vpopmail to fail the connection. To be more specific this will occur: 1: primary name server fails 2: When authentication to DB it takes a longer time due to system having to fail to secondary resolver. 3: vpopmail's auth to db starts failing due to timeouts (mysql takes to long to respond, but does respond), vpopmail tries harder to connect to db, connection count sky rockets (I saw upwards of 1400 connections) and in turn the connections do not close properly. 4: db locks up hard. 5: once you quiet down vpopmail (easiest way was to disable incoming access sadly), test messages show that an occasional message wil lgo through, but the rest receive the MySQL server has gone away message. 6. Trying to auth to db, albeit slightly slower than normal, responds and allows auth. Once in runs perfectly. 7. You realize that its primary dns server is off for whatever reason, start it, and voila no problem. Now admittedly, previously I've seen the same thing but for other reasons, this was just the more obscure annoying one. Yes I realize that a local dns server make a lot of sense for this situation, but if the named on that box stops, and it has your other name servers as secondary, WHEN are you gonna realize that? Most people would not add that to their monitoring. LOTS of fun. -Greg
RE: [vchkpw] Spotty behavior authenticating: MySQL server has gone away
Greg Swift wrote: Dallas L. Engelken wrote: -Original Message- From: ISP Lists [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 24, 2005 10:21 AM To: vchkpw@inter7.com Subject: Re: [vchkpw] Spotty behavior authenticating: MySQL server has gone away Something peculiar happened to mysql during a reboot and now vpopmail authdaemond is having trouble completing authentications /var/log/maillog says: Aug 24 08:36:15 hostname authdaemond: vmysql: sql error[3]: MySQL server has gone away This problem is spotty though. I have several successful authentications before this error occurs. I then have to restart mysqld before I can get any other authentications to succeed. I am still able to use the mysql client to connect to the server for an interactive session. What seems strange to me is that there are only two mysql daemons running: root 23923 0.0 0.1 5060 1108 pts/0S09:13 0:00 /bin/sh /usr/bin/safe_mysqld --defaults-file=/etc/my.cnf --pid-file=/var/run/mysqld/mysqld.pid mysql23956 0.0 0.5 38620 5656 pts/0Sl 09:13 0:00 /usr/libexec/mysqld --defaults-file=/etc/my.cnf --basedir=/var/lib --datadir=/var/lib/mysql --user=mysql --pid-file=/var/run/mysqld/mysqld.pid --skip-locking Every other instance of mysql 3.23.x I've ever run has about 10 child threads running, so this seems strange to see only one child thread. I have not updated any packages on this box recently. None at all, I swear. Suggestions to investigate? Googling on the MySQL server has gone away is a wild goose chase. Hrm, rebooting the box seems to have helped. Still same number of mysql daemons, but they're answering now... Damned strange. dmesg on reboot didn't show any ext3 errors being fixed - I was wondering if this was a disk thing. Thoughts still welcome and appreciated on this. Well.. just for reference (cause it took me a while to figure this one out)... if your box is running with multiple name servers configured for resolution, and the primary stops responding, you will see this same issue. What happens is the slight delay added to the auth sequence as the mysql fails to the secondary resolver causes the vpopmail to fail the connection. To be more specific this will occur: 1: primary name server fails 2: When authentication to DB it takes a longer time due to system having to fail to secondary resolver. 3: vpopmail's auth to db starts failing due to timeouts (mysql takes to long to respond, but does respond), vpopmail tries harder to connect to db, connection count sky rockets (I saw upwards of 1400 connections) and in turn the connections do not close properly. 4: db locks up hard. 5: once you quiet down vpopmail (easiest way was to disable incoming access sadly), test messages show that an occasional message wil lgo through, but the rest receive the MySQL server has gone away message. 6. Trying to auth to db, albeit slightly slower than normal, responds and allows auth. Once in runs perfectly. 7. You realize that its primary dns server is off for whatever reason, start it, and voila no problem. Now admittedly, previously I've seen the same thing but for other reasons, this was just the more obscure annoying one. Yes I realize that a local dns server make a lot of sense for this situation, but if the named on that box stops, and it has your other name servers as secondary, WHEN are you gonna realize that? Most people would not add that to their monitoring. LOTS of fun. -Greg Or, I would think, you could just add the server/client to the hosts file(s) and skip DNS entirely. Or use IP addresses.
RE: [vchkpw] Spotty behavior authenticating: MySQL server has gone away
I think that error is given when it cannot connect at all to the mysql server, and gives up.. we were getting it when we were trying to connect to a mysql server on another box then realized it was only listening on localhost on that box. -David -Original Message- From: ISP Lists [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 24, 2005 8:24 AM To: vchkpw@inter7.com Subject: [vchkpw] Spotty behavior authenticating: MySQL server has gone away Something peculiar happened to mysql during a reboot and now vpopmail authdaemond is having trouble completing authentications /var/log/maillog says: Aug 24 08:36:15 hostname authdaemond: vmysql: sql error[3]: MySQL server has gone away This problem is spotty though. I have several successful authentications before this error occurs. I then have to restart mysqld before I can get any other authentications to succeed. I am still able to use the mysql client to connect to the server for an interactive session. What seems strange to me is that there are only two mysql daemons running: root 23923 0.0 0.1 5060 1108 pts/0S09:13 0:00 /bin/sh /usr/bin/safe_mysqld --defaults-file=/etc/my.cnf --pid-file=/var/run/mysqld/mysqld.pid mysql23956 0.0 0.5 38620 5656 pts/0Sl 09:13 0:00 /usr/libexec/mysqld --defaults-file=/etc/my.cnf --basedir=/var/lib --datadir=/var/lib/mysql --user=mysql --pid-file=/var/run/mysqld/mysqld.pid --skip-locking Every other instance of mysql 3.23.x I've ever run has about 10 child threads running, so this seems strange to see only one child thread. I have not updated any packages on this box recently. None at all, I swear. Suggestions to investigate? Googling on the MySQL server has gone away is a wild goose chase. -- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.338 / Virus Database: 267.10.14/79 - Release Date: 8/22/2005
Re: [vchkpw] Spotty behavior authenticating: MySQL server has gone away
Something peculiar happened to mysql during a reboot and now vpopmail authdaemond is having trouble completing authentications /var/log/maillog says: Aug 24 08:36:15 hostname authdaemond: vmysql: sql error[3]: MySQL server has gone away This problem is spotty though. I have several successful authentications before this error occurs. I then have to restart mysqld before I can get any other authentications to succeed. I am still able to use the mysql client to connect to the server for an interactive session. What seems strange to me is that there are only two mysql daemons running: root 23923 0.0 0.1 5060 1108 pts/0S09:13 0:00 /bin/sh /usr/bin/safe_mysqld --defaults-file=/etc/my.cnf --pid-file=/var/run/mysqld/mysqld.pid mysql23956 0.0 0.5 38620 5656 pts/0Sl 09:13 0:00 /usr/libexec/mysqld --defaults-file=/etc/my.cnf --basedir=/var/lib --datadir=/var/lib/mysql --user=mysql --pid-file=/var/run/mysqld/mysqld.pid --skip-locking Every other instance of mysql 3.23.x I've ever run has about 10 child threads running, so this seems strange to see only one child thread. I have not updated any packages on this box recently. None at all, I swear. Suggestions to investigate? Googling on the MySQL server has gone away is a wild goose chase. Hrm, rebooting the box seems to have helped. Still same number of mysql daemons, but they're answering now... Damned strange. dmesg on reboot didn't show any ext3 errors being fixed - I was wondering if this was a disk thing. Thoughts still welcome and appreciated on this.
RE: [vchkpw] Spotty behavior authenticating: MySQL server has gone away
-Original Message- From: ISP Lists [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 24, 2005 10:21 AM To: vchkpw@inter7.com Subject: Re: [vchkpw] Spotty behavior authenticating: MySQL server has gone away Something peculiar happened to mysql during a reboot and now vpopmail authdaemond is having trouble completing authentications /var/log/maillog says: Aug 24 08:36:15 hostname authdaemond: vmysql: sql error[3]: MySQL server has gone away This problem is spotty though. I have several successful authentications before this error occurs. I then have to restart mysqld before I can get any other authentications to succeed. I am still able to use the mysql client to connect to the server for an interactive session. What seems strange to me is that there are only two mysql daemons running: root 23923 0.0 0.1 5060 1108 pts/0S09:13 0:00 /bin/sh /usr/bin/safe_mysqld --defaults-file=/etc/my.cnf --pid-file=/var/run/mysqld/mysqld.pid mysql23956 0.0 0.5 38620 5656 pts/0Sl 09:13 0:00 /usr/libexec/mysqld --defaults-file=/etc/my.cnf --basedir=/var/lib --datadir=/var/lib/mysql --user=mysql --pid-file=/var/run/mysqld/mysqld.pid --skip-locking Every other instance of mysql 3.23.x I've ever run has about 10 child threads running, so this seems strange to see only one child thread. I have not updated any packages on this box recently. None at all, I swear. Suggestions to investigate? Googling on the MySQL server has gone away is a wild goose chase. Hrm, rebooting the box seems to have helped. Still same number of mysql daemons, but they're answering now... Damned strange. dmesg on reboot didn't show any ext3 errors being fixed - I was wondering if this was a disk thing. Thoughts still welcome and appreciated on this. In you're /etc/my.cnf, add a variable to increase max_connections [mysqld] set-variable = max_connections=500 I had a similar problem with Mysql gone away error, and this solved it for me. D
