On Wed, Apr 11, 2007 at 11:47:53AM -0400, Brian Awood wrote: > On Apr 11, 2007, at 9:11 AM, Robert Klingsten wrote: > > >It all works great, works perfectly... until... > > > >Roughly 24 hours after I start the DSPAM daemon, it will simply > >stop processing the messages. It stops putting the DSPAM headers > >in the messages and from what I can tell, it's not even looking at > >them because it is not logging messages in the DSPAM logs. The > >only thing that gets logged is the 'unable to initialize tools > >context' message; killing and restarting the daemon process fixes > >the problem. Just this morning I've enabled debugging on DSPAM to > >see what gets logged that way. > > > >This is a tiny system compared to the other users seeing this > >problem roughly a year ago. I'm only receiving mail for about 20 > >users, 4 domains, and only have DSPAM enabled for about 5 of those > >users. > > > >I've seen references to DSPAM not being able to reach Mysql but it > >looks like to me that Mysql is fine since Postfix and Dovecot both > >are still able to get virtual user info out of it during when DSPAM > >isn't working. > > > >I've tried: > > > >upping DSPAM 'MySQLConnectionCache' to 25 > >upping MySQL 'max_connections' to 200 > > > >Any suggestions on where to go from here? I suppose I could simply > >kill and restart the DSPAM daemon every 18 hours or something, but > >I'd rather have a solution rather than a hack. > > > This is a bug in dspam's daemon mode. If mail doesn't come in for a > time period longer than mysql's connection timeout dspam doesn't > realize the connection has timed out and doesn't try to reconnect. > Increasing dspam's connection cache on a lightly loaded machine will > probably make it worse. You could try decreasing the connection > cache or increasing mysql's connection timeout. The only "real" fix > is to either not run in daemon mode or fix the source so dspam > reconnects to mysql. I haven't looked at 3.8.0 yet, so I'm not sure > if it's been fixed there or not. > > Brian > It is just my opinion, but if the DB is dropping a valid connection the DB configuration is broken. Connection timeouts are used to prevent badly behaved applications from tying up resources. That is not the case here. Now arguably, DSPAM could be more robust about re-establishing connections to DB backends that have dropped. Once we disabled the MySQL connection timeout "misuse" for DSPAM we have not had these problems again.
Ken
