Description of problem: The update to MySQL 4.1.22 introduces an 8-hour idle timeout on TCP/IP connections on all platforms, see http://dev.mysql.com/doc/refman/4.1/en/news-4-1-22.html The previous version did not have any timeout. The effect in my circumstances is that FreeRADIUS crashes every night because its database connections go away while the system is idle. Of course it would be better if FreeRADIUS just opened new connections, but I'd consider that the regression in RHEL4 is the new timeout in MySQL. Version-Release number of selected component (if applicable): mysql-server-4.1.22-2.el4 How reproducible: Always Steps to Reproduce: 1. Open a MySQL connection 2. Wait over 8 hours or 1. Start MySQL and FreeRADIUS configured to query a MySQL database 2. Wait over 8 hours Actual results: Connection has gone away; FreeRADIUS hangs and consumes all CPU on queries Expected results: Connection still there; FreeRADIUS responds to queries Additional info: Let me know if I should raise a bug against FreeRADIUS too/instead; its behaviour when the database connection goes away obviously isn't optimal.
Sorry, should have mentioned: I am working around this by setting mysqld's wait_timeout to 31536000 in /etc/my.cnf (that's the maximum, 1 year). This is probably long enough that we won't see any further crashes, but I still thought it was worth reporting the regression.
I would think setting the timeout to zero would produce the previous behavior, but in any case you can set it to more than the probable uptime of your server. I don't believe this is a bug and do not plan to second-guess upstream's choices.
You can't set the timeout to zero; MySQL thinks you mean 1 if you say 0, which is definitely not the right thing. It's taken me ages to work out why my previously working RADIUS server crashed every night; this is definitely a regression from the previous behaviour, and I would have thought it was worth at least a little more documentation or something.