Bug 493030 - MySQL connections time out
MySQL connections time out
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: mysql (Show other bugs)
All Linux
low Severity medium
: rc
: ---
Assigned To: Tom Lane
Depends On:
  Show dependency treegraph
Reported: 2009-03-31 07:43 EDT by John Robinson
Modified: 2013-07-02 23:22 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-03-31 09:31:08 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description John Robinson 2009-03-31 07:43:14 EDT
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):

How reproducible:

Steps to Reproduce:
1. Open a MySQL connection
2. Wait over 8 hours

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 07:47:24 EDT
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 09:31:08 EDT
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 09:39:29 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.