| |> I'm running several QMT servers with spamdyke, and am now of the opinion |> that there's a bug in spamdyke. All are running v4.0.10. Also, I believe |> that DNS resolution is configured and working properly in all cases |> (local caching DNS, forwarding to root servers), so that should not be |> an issue. |> |> On low volume servers, only 1 of 3 had any defunct processes at all. |> They were few (1-2 per month) and very old (1-2 months old). Where I |> still had the corresponding log entries, I saw the tcpserver:pid and |> tcpserver:ok messages, but nothing else. No further messages from any |> smtp-related program. |> |> On a high volume server, defunct processes are much more frequent. They |> all appear to be sessions with a spamdyke:TIMEOUT message, although |> there are also many TIMEOUTs which do not result in defunct processes. |> The defunct sessions vary as to the type of rejection, some rDNS, some |> RBLs, but they all eventually get a TIMEOUT message, but no subsequent |> tcpserver:end message. |> | | I'm also experiencing this, although I'm not sure I'd consider my server a | high-volume server, but it's certainly not low-volume... Maybe | mid-volume? | :-) | | At any rate, the number of "hung" SMTP sessions slowly grows over time, | with | about 300 hung sessions in a two week period. A reboot clears them, and | the | cycle starts over. | |>From other posts here, I've checked, and also find many "defunct" | qmail-smtpd processes, with matching spamdyke process. | | I'm running spamdyke4.0.2. This is not on a Qmail Toaster box, rather a | Qmailrocks box that hasn't been pulled down yet. :-) But, it's exhibiting | the same symptoms. | | Let me know if you need anything specific to help figure out the issue | Sam. |
We use 4.0.10 on a toaster implementation, and found that dns latency caused the defunct spamdyke processes on our systems. Not to say this is the same thing you folks are experiencing, but I think it would be nice if there is a "denied" message sent to the sending connection, an immediate disconnect (such as the idle-timeout when the value is reached) would occur. I think that would help reduce the load (here at least) and eliminate the Timeouts. We seem to require the idle-timeout value (and anything higher than 60 in our case give very high smtp concurrency values upwards to 500) to keep the server in line. But again in our case we put a local to the server dnscache on the mailer, and also have it check our local network dnscaches as a secondary dns and then our upline provider dnscache. This solved our defunct spamdyke processes. Our load varies from 300K to 1M messages per day/server, most of which is junk. BTW, not using the idle-timeout smokes the servers with concurrent connections. best greg _______________________________________________ spamdyke-users mailing list [email protected] http://www.spamdyke.org/mailman/listinfo/spamdyke-users
