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/0 S 09:13
0:00 /bin/sh
/usr/bin/safe_mysqld --defaults-file=/etc/my.cnf --pid-file=/var/run/mysqld/mysqld.pid

mysql    23956  0.0  0.5 38620 5656 pts/0    Sl   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

Reply via email to