For your problem, first check any local IPTables firewall rules you have an make sure you're not doing something silly that will block fin packets that don't have the ack bit set.
Next I would check for kernel upgrades. It's possible there's a subtle bug in the version of the kernel your running, but this seems like an unlikely case.
That aside, it is possible to adjust the fin timeout in /proc. This is DANGEROUS and not recommended, but is possible.
The entry you want to change to adjust this is tcp_fin_timeout, but be warned that the Linux kernel already uses the minimum "safe" value for this timeout, and that there are cases where even the defaults aren't safe.
At 11:32 AM 10/29/2002 -0600, James Bly wrote:
Perhaps someone has seen this before so I ask: Recently I rebuilt a relay using RedHat 8.0. Went with the latest version of SA at the time and I'm starting to see spamc intermittently fail. Iptables has been ruled out as being connected with this. (Was my first suspicion.)
Basically I see spamc connections coming up in a "trapped" FIN_WAIT2 state. They will sit there and eventually fill up instances of qmail to where it stops taking requests off the network. (Note also that I'm running spamc from qmail-qfilter which is called through the qmail-queue patch. I am not currently able to attribute any of this to qmail.)
The netstat below and ps output is about all I've been able to gather so far. If anyone has any ideas on ways to trace this issue, let me know. The only hypothesis I can build thus far as that a particularly malformed mail is causing spamd to trip up and the spamc sessions to hang, but that's all conjecture.
Thanks in advance for any ideas people may have,
-James
\
------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
