SOLVED!
Read on....
On May 25, 2005, at 1:37 PM, Tom Collins wrote:
On May 24, 2005, at 7:25 PM, Matt Simerson wrote:
So, I turned to vmysql.c and noticed a timeout setting there that
affects the mysql connection timeout. I bumped it up from 2 to 5, and
it has reduced the failure frequency but it's still happening fairly
regularly. There are some slow queries in MySQL, but only 15 from the
last day, so that doesn't even closely correspond with 300 "no found"
errors.
So, anyone got ideas on how to debug this issue further?
Thanks for taking such a detailed look at this problem. I think
you've nailed it right there -- the server (or MySQL) gets bogged
down to the point where it can't answer the query in under 5
seconds. Vpopmail times out and its only option is to reply that
the login failed.
Increasing that timeout to 10 or even 15 seconds shouldn't have a
negative impact -- it will make vpopmail more tolerant of slow
responses.
--
Tom Collins - [EMAIL PROTECTED]
I would love to believe that this issue was that simple. Last night
while running the buildworld, the system was very heavily loaded.
During that time, I had the timeout raised to 5 seconds and was
running my test script which runs one query every second. The
queries that failed were failing much sooner than the 5 second timeout.
Further, the other program that I was accessing MySQL with never once
failed, and it never took more than a second or two to return the
results either.
Further still is that the timeout value that I altered in vmysql.c
ONLY affects the MySQL connection timeout (MYSQL_OPT_CONNECT_TIMEOUT)
which is only used in mysql_real_connect. Since it's always
connecting to MySQL in well under 5 seconds, that certainly is not
the problem, and raising it to any arbitrarily higher number isn't
going to help.
As Matt B pointed out in his post where he saw this issue previously,
vpopmail is successfully connecting to the MySQL server, and in 99.9%
of the cases (even where authentication failure occurs), successfully
switching to the vpopmail database correctly.
Today I added a new data point to the mix. I upgraded another mail
server for a different client, also FreeBSD. Previously using MySQL
3.x. Fairly moderate load, but a much more busy server that's been
happily busy since I build it for him, two years ago. I also
upgraded this box to MySQL 4.0 w/linuxthreads. I began getting the
failed authentications in the logs again. He complained that
qmailadmin wasn't working correctly (while I was still compiling) and
sure enough, when the system was under moderate load, I was getting
Apache errors in the log file:
vmysql: sql error[5]: Commands out of sync; You can't run this
command now
vmysql: sql error[5]: Commands out of sync; You can't run this
command now
vmysql: sql error[5]: Commands out of sync; You can't run this
command now
vmysql: sql error[5]: Commands out of sync; You can't run this
command now
vmysql: sql error[5]: Commands out of sync; You can't run this
command now
vmysql: sql error[5]: Commands out of sync; You can't run this
command now
vmysql: sql error[5]: Commands out of sync; You can't run this
command now
vmysql: sql error[3]: MySQL server has gone away
I didn't bother to read the qmailadmin source and understand it's
error messages, I just compiled a new mysql-server w/o linuxthreads,
installed it and all the MySQL problems went away. It may simply be
coincidence that this fixes the problem on two different systems, but
it's a happy coincidence for me.
Matt