This kind of thing has been requested before but unfortunately there's 
currently no way to log the total number of running spamdyke processes. 
  Because spamdyke is not a daemon, there is no "master" process that 
can count the number of spamdyke children.  Someday that may change.

spamdyke does create log entries for every connection, either because a 
message was rejected or because the timeout was reached.  Although you 
can't use those log messages to find out how many spamdyke processes are 
running in any given moment, you can analyze them to find out how many 
are running over a given time period (connections/rejections per hour, etc).

Perhaps it would be useful if spamdyke (optionally) created a log entry 
on exit to show how long it ran, possibly detailing the amount of time 
it spent running filters, waiting on qmail and waiting on the remote 
server.  That might make it easier to figure out why a server is running 
slowly and what should be done to speed it up.  I'll give that some thought.

-- Sam Clippinger

Ulrich Eckardt wrote:
> Hi Sam and list,
>  
> just thought, I´ld give you some feedback on what worked finally.
>  
> We had the strange situation that the smtp ports just got plugged and it 
> was partially impossible for customers to open a connect for sending 
> mails ... and of course for other mailservers to deliver to ours.
>  
> Bad situation on a production system (problems like that never occured 
> in testing env.)
>  
> I tried about everything I could configure with spamdyke and other progs 
> to get the problem solved ... I even took all ips from the logfile that 
> had DENIED_RDNS entries and dropped them on kernel basis to get ride of 
> connections and free smtp again ... Only worked for a moment.
>  
> BTW, there is a ratio of 16:1 in DENIED_RDNS, meaning on a daily basis 
> ips with no rdns mad on naverage 16 attemps to connect.
>  
> Anyway, /var/log/qmail/smtpd/current showed a total of no more than 200 
> connections, our maxconcurrency was set to 1024 - so obviously enough 
> romm .....
>  
> Wrong.
>  
> Thats 200 qmail-smtpd connections ... and when for each qmail-smtpd 
> connect you have a ton of spamdyke dns tests and other connects ... that 
> means that tcpserver has reached its 1024 limit, even if current only 
> shows 200 qmail-smtpds.
>  
> I raised maxconcurrency to 8192 and guess what ... load on the 
> mailservesr reached the normal level again, since all incoming 
> connections are working again.
>  
> So, not exactly a bug, but something which might be a nice addon: 
> Logging the connects of spamdyke - maybe in addition to the qmail-smtpd 
> connects, so you have control over active connections compared to 
> maxconcurrency.
>  
> This would have saved me quiet some trouble with pretty angry customers.
> Maybe somebody more sophisticated than me is able to patch tcpserver 
> itself to produce such an outpiut in a logfile ...
>  
> ------------------------------------
>  
> And a hand shell line, to find out, who is producing the connections:
> for i in `cat /var/qmail/control/morercpthosts`; do echo -n $i >> 
> /root/mails && cat /var/log/mail.log.0 | grep $i | wc -l >> /root/mails; 
> done
>  
> This produces a nice list of logentries per domain per day (depending on 
> your logrotate).
>  
>  
> Thanks for reading - u.
>  
>  
>  
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> spamdyke-users mailing list
> [email protected]
> http://www.spamdyke.org/mailman/listinfo/spamdyke-users
_______________________________________________
spamdyke-users mailing list
[email protected]
http://www.spamdyke.org/mailman/listinfo/spamdyke-users

Reply via email to