Description of problem: mysqld/safe_mysqld segfault whenever a connection is made thru internet (or outside it's network) with a 56kbps connection. Version-Release number of selected component (if applicable): mysql-3.23.54a-4 mysql-server-3.23.54a-4 both source and binary How reproducible: every time Steps to Reproduce: 1.service mysqld stop 2.su - mysql 3./usr/bin/safe_mysqld --defaults-file=/etc/my.cnf >/dev/null 2>&1 & 4.then try to connect at port 3306 with mysql or telnet it would drop the connection and segfault. Actual results: ----Server side result: /usr/bin/safe_mysqld: line 278: 23776 Segmentation fault $NOHUP_NICENESS $ledir/$MYSQLD $defaults --basedir=$MY_BASEDIR_VERSION --datadir=$DATADIR $USER_OPTION --pid-file=$pid_file --skip-locking >>$err_log 2>&1 ----Client Side result: ERROR 2013: Lost connection to MySQL server during query Expected results: spawns to mysql monitor environment Additional info: it is always replicable on both default binary and recompiled binaries from original source from redhat
One quick solution is to put the ip address of the client to /etc/hosts of server. Downfall of the solution, you can't add a non static ip address of clients from time to time. I used a dialup connection and my ip address is not static. Is there a solution or patch to the mysql source? This bug is reproducible even to the new compiled version of mysql 4.0.9 gamma. Haven't tested yet on 4.1 alpha. I hope this won't result on remote exploitation.
This is fixed in glibc, but the current rawhide version might be just too much NPTL-based to be usable on RHL 8.0. Search bugzilla for previous reports of the same issue (on both RHL 8.0 and 7.3). BTW, NEEDINFO means that the RH developers want input from you, not the other way around. Setting it to NEEDINFO may result in getting ignored ;-)
Thank you for the tips miloslav and correction. I hope I could use bugzilla more efficient as much as possible so not to duplicate reports. I just browse from previous reports and found this [mysqld] skip-name-resolv That solves the problem on my box. I don't know if that would work for others. As I had read from other reports the problem might be from the new glibc although I don't understand why some programmers try to resolve from ip to name on a tcp/ip handshake of a database daemon. If I am not mistaken redhat syslogd or perhaps other daemons already or may have done that and output it at the log file. Oh well I just wonder.... Correct me if I'm confused. *** This bug has been marked as a duplicate of 74943 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.