I'd ruled out iptables by stopping it. The problems persisted, although it had to run like that for two days before they showed up again. (iptables was only being used for basic local firewalling, for the record. This system is still firewalled from the internet and does not accept connections from internet hosts.)
----------------- [root@boink root]# iptables -L -n Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination ---------------- My confusion is much like that of your surprise. The reason these processes are getting hung up is quite unclear. RedHat 8.0 uses 2.4.18-14. (No modifications from the default installed kernel.) Coincidentally, after fixing the problem two hours ago by killing the processes, it has once again started to do it. (Shortest time frame I've seen it repeat the issue.) If anyone comes across any good troubleshooting ideas in the next hour or two, please feel free to email me directly. I'll be playing with it to see if I can somehow find some connection that might lead me to the issue. -James -----Original Message----- From: Matt Kettler [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 29, 2002 1:05 PM To: James Bly; '[EMAIL PROTECTED]' Subject: Re: [SAtalk] Odd intermittent failure, (RH8, SA 2.42, Perl 5.8) It's surprising to me that connections from a local client to a local server are being trapped in FIN_WAIT2. There's nothing an application can really do to mess up the closing of connections, so I'd susspect a bug in your firewall rules, or your linux kernel. Connections for TCP should smoothly enter the TIME_WAIT state when closing unless the fin packet from the server socket is somehow missed. For a loopback connection this should never happen. The TIME_WAIT state is mandatory for the stable operation of TCP and is not avoidable. 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
