Red Hat Bugzilla – Bug 75297
glibc-2.2.5-40 and mysql-3.23.49-3 are not working together
Last modified: 2007-04-18 12:47:15 EDT
mysql-server-3.23.49-3 and mysqlclient9-3.23.22-6 and php-mysql-4.1.2-7.3.4
RHL 7.3 when I update to the new glibc update series glibc-2.2.5-40, it stops
using the older glibc -39 patch level, and a ldconfig, and a reboot, and ...
mysql begins working again
[herrold@server3 herrold]$ sudo su -
[root@server3 root]# mysql -u root -p obcc
ERROR 2002: Can't connect to local MySQL server through socket
[root@server3 root]# rpm -qa | grep sql
[root@server3 root]# rpm -qi mysql-server
Name : mysql-server Relocations: (not relocateable)
Version : 3.23.49 Vendor: Red Hat, Inc.
Release : 3 Build Date: Mon 08 Apr 2002 06:57:54
Install date: Fri 14 Jun 2002 03:21:00 PM EDT Build Host:
Group : Applications/Databases Source RPM: mysql-3.23.49-3.src.rpm
Size : 3923447 License: GPL
Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
URL : http://www.mysql.com
Summary : The MySQL server and related files.
MySQL is a true multi-user, multi-threaded SQL database server. MySQL
is a client/server implementation that consists of a server daemon
(mysqld) and many different client programs and libraries. This
package contains the MySQL server and some accompanying files and
[root@server3 root]# netstat -an
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:32768 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:32769 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:515 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:23 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:6010 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:6011 0.0.0.0:* LISTEN
tcp 1 0 10.30.0.253:3306 10.30.0.253:33053 CLOSE_WAIT
tcp 1 0 10.30.0.253:3306 10.30.0.253:33054 CLOSE_WAIT
tcp 1 0 10.30.0.253:3306 10.30.0.253:33055 CLOSE_WAIT
tcp 1 0 127.0.0.1:3306 127.0.0.1:33060 CLOSE_WAIT
tcp 1 0 127.0.0.1:3306 127.0.0.1:33061 CLOSE_WAIT
tcp 6 0 127.0.0.1:3306 127.0.0.1:33062 CLOSE_WAIT
tcp 0 0 10.30.0.253:3306 10.30.0.253:33056 ESTABLISHED
tcp 0 0 10.30.0.253:3306 10.30.0.253:33057 ESTABLISHED
tcp 0 0 10.30.0.253:3306 10.30.0.253:33058 ESTABLISHED
tcp 1 0 127.0.0.1:3306 127.0.0.1:33059 CLOSE_WAIT
tcp 0 0 10.30.0.253:33058 10.30.0.253:3306 ESTABLISHED
tcp 0 0 10.30.0.253:33057 10.30.0.253:3306 ESTABLISHED
tcp 0 0 10.30.0.253:33056 10.30.0.253:3306 ESTABLISHED
tcp 0 0 10.30.0.253:22 10.10.10.7:60616 ESTABLISHED
tcp 0 0 10.30.0.253:22 10.10.10.7:60661 ESTABLISHED
tcp 30 0 10.30.0.253:33063 22.214.171.124:21 CLOSE_WAIT
tcp 1 0 10.30.0.253:3306 10.30.0.254:53894 CLOSE_WAIT
udp 0 0 0.0.0.0:32768 0.0.0.0:*
udp 0 0 0.0.0.0:111 0.0.0.0:*
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags Type State I-Node Path
unix 2 [ ACC ] STREAM LISTENING 225191 /var/lib/mysql/mysql.sock
unix 2 [ ACC ] STREAM LISTENING 1525 /dev/gpmctl
unix 9 [ ] DGRAM 1060 /dev/log
unix 2 [ ACC ] STREAM LISTENING 1595 /tmp/.font-unix/fs7100
unix 2 [ ACC ] STREAM LISTENING 1397 /var/run/lprng
unix 2 [ ] DGRAM 228150
unix 2 [ ] DGRAM 1598
unix 2 [ ] DGRAM 1545
unix 2 [ ] DGRAM 1500
unix 2 [ ] DGRAM 1348
unix 2 [ ] DGRAM 1124
unix 2 [ ] DGRAM 1069
[root@server3 root]# lsof -i TCP:3306
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
mysqld 5999 root 3u IPv4 225189 TCP *:mysql (LISTEN)
mysqld 5999 root 7u IPv4 225198 TCP
dial-to-d 6041 root 3u IPv4 228148 TCP
intertel- 6042 root 3u IPv4 228835 TCP
db-to-int 6043 root 4u IPv4 228151 TCP
... even though attempts to connect are started, nothing ever gets returned ...
[root@server3 root]# rpm -qa --last
glibc-utils-2.2.5-39 Sun 06 Oct 2002 07:55:28 PM EDT
glibc-devel-2.2.5-39 Sun 06 Oct 2002 07:55:26 PM EDT
glibc-2.2.5-39 Sun 06 Oct 2002 07:55:17 PM EDT
glibc-common-2.2.5-39 Sun 06 Oct 2002 07:55:08 PM EDT
tar-1.13.25-4.7.1 Sun 29 Sep 2002 08:14:40 AM EDT
vnc-3.3.3r2-28 Sat 28 Sep 2002 10:14:54 AM EDT
It may be that this should be filed against glibc -- I am trying to reproduce on
a non-SMP processessor (the one with the problem is a Dell 2450 with two
I am having a similar problem. After the glibc patch:
1) I can connect to mysqld (using localhost) as usual
2) I CANNOT connect to mysqld (using IP address) with the following message:
ERROR 2013: Lost connection to MySQL server during query
The mysql log file says:
Number of processes running now: 1
mysqld process hanging, pid 30656 - killed
021009 23:29:22 mysqld restarted
/usr/libexec/mysqld: ready for connections
This is the same as 75290.
I also experienced this on a uni-processor system. However, I did not have to
do an ldconfig or reboot to fix it. I simply downgraded to glibc-2.2.5-39 and
Remote connections kill mysql, but local connections (TCP or UNIX socket) do not
cause MySQL to die.
Same here. Server i686 Uniprocessor, Client i686 Uniprocessor, both on RHL 7.3
with all upgrades. Definitely reproduceable. glibc-2.2.5-40.i686.rpm
We were able to fix this on our SMP box by replacing the glibc-common and glibc
packages from the RH 7.3 disk 1 CD.
rpm -i --replacefiles --oldpackage glibc-common-2.2.5-34.i386.rpm
rpm -i --replacefiles --oldpackage glibc-2.2.5-34.i686.rpm
We DID NOT have to restart MySQL. It worked immediately after the replace.
However, it would probably be good to restart.
Lenz with mysql.com said that RedHat is investigating this issue. It seems
clear that there is something conflicting with the glibc*-2.2.5-40.* packages.
I have 4 servers with nearly identical setup, 1 of them is SMP while the others
only have one processor, I only have the problem on the SMP machine.
Where can I find the -39 rpms? I wasn't able to find them so I'm going back to
the ones on the 7.3 cd
On a machine with 1 processor, local mysql connections work fine, but remote
ones cause the mysql server to restart just as reported above.
i use a portforwarding from external ip to 127.0.0.1:3306 as a workaround...
Mysql 3.23.53a works with the latest mess of a glibc. Of course this isn't a
current Red Hat RPM but the standard mysql.com version.
[jhood@corduroy tmp]$ rpm -q MySQL
[jhood@shrubbery SPECS]$ mysql -p -h corduroy
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 2 to server version: 3.23.53a
Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
Caution, I do have a modified glibc to have Red Hat work with PostgreSQL --
mktime bug fix:
[jhood@corduroy tmp]$ rpm -q glibc
I have a single-processor MySQL server being accessed by a single remote client.
As previous people stated, all connections over loopback worked just fine, all
remote connections caused an immediate seg fault.
rpm -Uvh --oldpackage glibc-common-2.2.5-39.i386.rpm glibc-2.2.5-39.i686.rpm
To RH: Please issue either a fixed glibc or one of the newer (and by all
accounts) working MySQLs! This effects _all_ MySQL users, not just SMP boxes.
We are running 7.2 with a 2.4.18-17.7.x kernel on a single processor. glibc-
2.2.4-30 as per Red Hat Erata along with mysql-server-3.23.41-1.
We are experiencing a problem already posted regarding not being able to
connect remotly. The server is running and answering on the local host. but no
remote connection can be established.
Is there a workaround without going back to an older version of glibc ?
I concur that the issue is the glibc expectations, not being the same as the
serer applications already extant -- it is not a SMB issue so far as I can tell.
I have just filed as to TFTP server a similar bug in RHL 8.0
I don't know how this bug has still not been marked as a duplicate
They closed a bug like this when they released the new glibc package last week.
I can't find the bug number now, but it's in the RHSA for the new glibc.
This was possibly SMP related; and on a differing RHL version -- it is not clear
that it is fixed -- it is in my queue for testing.
This may explain the non-close for the moment ... I will close it myself
if/when my testing concludes it _is_ resolved on the host in question -- but the
host houses a production database, and I need to travel to that site before I
possibly hork it up -- I am scheduled to do so next week.
Just going through the existing backlog and noticed this was not
marked as a duplicate of 75128. There was a problem with MySQL
interation with the updage glibc (which has been fixed). Please
look at 75128 for more information.
*** This bug has been marked as a duplicate of 75128 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.