Interestingly, adjusting the wait_timeout to the default (8 hours) worked
great - for 8 hours. After that 8 hours, RT once again lost all
connectivity to the database. Running a show processlist on MySQL showed
that RT had no connections to the DB, even though RT was still running. A
restart fixed it - for now.
I am not sure how RT does connection handling, but it seems like it should
attempt to reconnect?
On Fri, Nov 22, 2013 at 8:32 AM, Jay Christopherson
jc.listm...@gmail.comwrote:
Ken, thanks for the suggestion/reminder - I cribbed a my.cnf file from
another database I setup. I had forgotten that I set a short wait_timeout
(300), for just the reason you suggested. I reset it to be a little more
sane about an hour ago and so far, things look ok.
On Fri, Nov 22, 2013 at 5:37 AM, k...@rice.edu k...@rice.edu wrote:
On Thu, Nov 21, 2013 at 06:05:23PM -0800, Jay Christopherson wrote:
No, no entries beyond the startup messages. I thought maybe there
would be
some connection errors (a flush-hosts situation or something), but
nothing.
On Thu, Nov 21, 2013 at 6:02 PM, Alex Vandiver
ale...@bestpractical.comwrote:
On Thu, 2013-11-21 at 15:20 -0800, Jay Christopherson wrote:
I just installed a new instance of RT (4.2.1). I've been using RT
for
quite a long time now, through a lot of different versions, but this
is a new issue for me.
Is there anything of note in the mysql logs?
- Alex
Hi Jay,
It might be a long shot, but do you have a connection timeout set for your
MySQL DB? Try disabling that. I was bit by that once and was astounded to
find out that the DB just dropped a valid connection like that. It seems
more useful in a broken web app type of way to keep from leaking
connections
but normal apps do not expect to lose a good connection. :)
Regards,
Ken
