Bug #2009 'Random' connection failures across a network
Submitted: 4 Dec 2003 2:50 Modified: 4 Dec 2003 7:55
Reporter: [ name withheld ] Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server Severity:S1 (Critical)
Version:4.1.0-Alpha OS:Linux (RH Linux 9)
Assigned to: CPU Architecture:Any

[4 Dec 2003 2:50] [ name withheld ]
Description:
Scenario:
2 RH 9 servers, latest patches applied to OS.  Servers communicate across a private LAN.  Server 1 is primary DB - 192.168.0.201.  Server 2 is slave DB and client of server 1 - 192.168.0.203.

Server 1
GRANT SELECT on *.* TO user@192.168.0.203 identified by 'this is a long password'

Server 2
Using either Perl (DBI) or PHP (mysqlclient 4.1 libs), initiate a connection to Server1.  It will either fail or work.  Every time that it fails, it returns the message (logged in the server log as well) 'Access denied for user: 'user@192.168.0.203' (Using password: YES)'.  

Testing steps taken:
Created a perl script to loop 100 times the series 'connect ; disconnect'.  Within the 100 tries, the connection would fail.  It seems impossible to predict the failure point.  It may fail on the first connection, or the 90th.

Revoked the GRANT and re-issued with no password.  Ran the same perl script from server2 numerous times (5000+ connect/disconnect tries).  No failure whatsoever.

Revoked the GRANT and re-issued with a 1 character password.  Ran the same perl script ~2000 times and no failure seen.

Revoked the GRANT and re-issued with an 8+ char password.  Failure within 100 connection attempts.

At least one other case of this has been reported on the mysql (general) list in the past week (subject 'error 1045 happened randomly' author 'francis@mixmedia.com').

rpm queries:
MySQL-server-4.1.0-0
kernel-2.4.20-20.9
glibc-2.3.2-27.9

How to repeat:
#!/usr/bin/perl
use DBI;

$|=1;
# Set up the DB connection
my $dsn = "dbi:mysql:host=192.168.0.201;database=test";
my $user = 'user';
my $password = '';

$bar = 0;
while ($bar < 100) {
        $dbh = DBI->connect($dsn, $user, $password, {PrintError => 1});
        if ($DBI::errstr) {
                print "!";
        } else {
                print ".";
        }
        $dbh->disconnect();
        $bar++;
}

Suggested fix:
Unknown.
[4 Dec 2003 6:44] Dean Ellis
I experienced something similar with 4.1.0 and early in the 4.1.1 tree, however it no longer occurs.  Binaries for 4.1.1 should be available any day now, so would it be possible for you to test against that version and see if the problem persists?

Thank you
[4 Dec 2003 6:47] [ name withheld ]
Certainly.  I'll wait for the RPMS to hit the mirrors and give it a spin.
[4 Dec 2003 7:49] [ name withheld ]
4.1.1 definitely seems to clear up the issue.  Just ran 4000 
connect/disconnect pairs, and nary an error with a password of 'a long 
password with spaces and other spaces'  (which is the password I was testing 
with). 
 
I did notice that the rpm upgrade (Fvh) nuked my permissions tables, so I'll 
have to do that more carefully next time.
[4 Dec 2003 7:55] Dean Ellis
I will assume the issue was corrected in 4.1.1, then, and close the report.

The release announcement mentions that the password format has changed in 4.1.1, incidentally, which is what "nuked" the permissions.  You have to reset your passwords if you are using the new, long password format.

Thank you
[4 Dec 2003 8:42] [ name withheld ]
A minor followup for this issue.  A DBD::mysql driver compiled with the 4.1.1 
libraries does not suffer from the issue, even when talking to a 4.1.0 server.