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.com>wrote: > 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.com>wrote: >> > >> > > 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 >> > >