Bug 493030

Summary:	MySQL connections time out
Product:	Red Hat Enterprise Linux 4	Reporter:	John Robinson <john.robinson>
Component:	mysql	Assignee:	Tom Lane <tgl>
Status:	CLOSED NOTABUG	QA Contact:	BaseOS QE <qe-baseos-auto>
Severity:	medium	Docs Contact:
Priority:	low
Version:	4.7	CC:	byte, hhorak
Target Milestone:	rc
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2009-03-31 13:31:08 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description John Robinson 2009-03-31 11:43:14 UTC

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.

Comment 1 John Robinson 2009-03-31 11:47:24 UTC

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.

Comment 2 Tom Lane 2009-03-31 13:31:08 UTC

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.

Comment 3 John Robinson 2009-03-31 13:39:29 UTC

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.