Greetings Eric, Yes, indeed it is helping with the cleanup of stale connections.
Thanks for the heads up. ------------------------ Erald Troja Eric Shubert wrote: > Erald Troja wrote: >> Hello all, >> >> We are using Hsphere control panel automation offered >> from Parallels with precompiled Qmail binaries. >> >> Our entry onto the spamdyke /etc/init.d/qmaild script which >> is currently running on a CentOS 4.6 is as follows. >> >> at the very top we define SPAMDYKE and it's configuration file >> >> SPAMDYKE="/usr/local/bin/spamdyke --config-file /etc/spamdyke/spamdyke.conf" >> >> further down onto the start portion of /etc/init.d/qmaild we issue (all >> in one line) >> >> tcpserver -v $RRDNSKEY -R -c $TCP_SERVERS $IPLIMIT $RELAYCHKARG -u >> $USER_VPOPMAIL -g $GROUP_VCHKPW 0 smtp $SPAMDYKE $RBL qmail-smtpd vchkpw >> true cmd5checkpw true 2>&1 | splogger smtpd & >> >> Our Spamdyke configuration file is as follows. /etc/spamdyke/spamdyke.conf >> >> log-level=info >> graylist-level=always-create-dir >> graylist-dir=/var/tmp/spamdyke.graylist.d >> graylist-exception-ip-file=/etc/spamdyke/whitelist.conf >> graylist-min-secs=1200 >> graylist-max-secs=4322000 >> reject-unresolvable-rdns=true >> reject-empty-rdns=true >> >> >> Our maximum tcpsessioncount is set to 1000. This has been working >> fine for when our Qmail server was operating without Spamdyke. >> >> Recently we've hit the limit of tcpsessioncount twice. I've been >> monitoring the log files and this happens slowly but surely. >> >> I'd like to ask, why, and what can we do to prevent this and make it. >> Raising tcpsessioncount is an option, yet I believe we will slowly but >> surely reach the limit as well. >> >> Thank you. >> > > Try adding: > idle-timeout-secs=660 > to your configuration file. I'm betting that will fix you up. ;) > > See http://spamdyke.org/documentation/README.html#TIMEOUTS for details. > _______________________________________________ spamdyke-users mailing list [email protected] http://www.spamdyke.org/mailman/listinfo/spamdyke-users
