OT: sendmail cmd read

[campbell at cnpapers.com]

Greg, thanks very much. See a few comments below:

Quoting Greg Matthews <gmatt at nerc.ac.uk>:

> Steve Campbell wrote:
> > This is OT, and may have been discussed before... but here goes anyway. 
> > Google didn't show much on this one.
> > 
> > I am fighting a machine that has recently starting showing increased 
> > load averages. What used to stay below 5 is now climbing into the 11.+ 
> > at times, and stays around 8 for most of the day. I have considered bdc 
> > as the culprit, but really, this hasn't changed recently, as I have not 
> > really changed anything for a while. I did install a caching name 
> > server, but see little improvement. I'm not looking for additional 
> > "fixes" so much as resolving the problem of what is causing this when 
> > changes haven't been made. The load climbs when MailWatch shows 8+ 
> > MailScanner processes (I have 5 set in Mailscanner.conf) and around 50 
> > sendmail processes. I don't think the version of Mailscanner had 
> > anything to do with this (4.52.2), and I am running this on two other 
> > servers without the problem - and clamav and bitdefender on the others 
> > also.
> > 
> > A 'ps -ax | grep sendmail' has always shown a lot of processes to of the 
> > form:
> > 
> > sendmail: server [IP address] cmd read
> > 
> > These usually have common IP addresses, and I wonder, firstly, what is 
> > sendmail really doing at this point, and secondly, is there something 
> > that I can do that will make the longer-lived processes go away if these 
> > are bad connections? These sendmail processes tend to gradually climb to 
> > a level of around 40-50, and never really drop without restarting 
> > sendmail. I haven't checked to see if they are the same process IDs. I 
> > have an idea that these are uncompleteable (?) sendmail connections that 
> > are started, but not sure.
> 
> you've pretty much identified the problem here. sendmail processes are 
> hanging around which is reflected in the rising load average. In fact 
> the host is probably not using many cpu cycles but there are a lot of 
> sendmail processes in the queue. It looks like external mail hosts are 
> connecting to your box but being really slow at communicating. This 
> could be an attempt to slow down/stop your mail server by connecting 
> until the max connections is reached thus stopping anyone else 
> connecting. Stopping or restarting sendmail will not usually kill these 
> connections, to do so, issue a "pkill sendmail" which will close them down.

Up until now, I would ususally have to "killall sendmail" to flush these. They
would go on forever.
> 
> > 
> > I'm sure there is a setting in sendmail (8.12 for now)  that might fix 
> > this (as sort of a timeout thing) , or maybe a milter, but I haven't 
> > found it yet. I would like to understand, though, what may have caused 
> > the increased load averages, other than the varying input to sendmail. I 
> > realize this could be a major factor, but don't see a lot of change in 
> > the usual crap that comes in daily. Around 40K+ messages a day with 
> > about 85-90% spam caught. This has been constant for a long time.
> 
> you can limit the max number of connections, rate of connection and 
> impose limits per ip address (you'll have to check how much of this you 
> can do with 8.12, I use 8.13). Look at:
> confCONNECTION_RATE_THROTTLE
> FEATURE(`ratecontrol', ,`terminate')
> FEATURE(`conncontrol', ,`terminate')
> a good place to read about managing this sort of thing is:
> http://www.technoids.org/dossed.html

I'll try the link, and for now, have changed a lot of the timeout values for the
default sendmail.mc that RH ships. I recall ages ago, like RH 6.2, that the
ident timeout used to require zeroing or sendmail would come to a real halt, but
had not needed any other changes since then. This has made the average number of
sendmail processes drop to about 20 or less, but the load still swings to a high
8 or 9, for what looks like no apparent reason.
> 
> good luck

Thanks for the help.

Steve
> 
> GREG
> 
> > 
> > Opinions would be greatly appreciated. Thanks!
> > 
> > Steve Campbell
> > campbell at cnpapers.com
> > Charleston Newspapers
> > 
> > 
> 
> 
> -- 
> Greg Matthews           01491 692445
> Head of UNIX/Linux, iTSS Wallingford
> 
> -- 
> This message (and any attachments) is for the recipient only. NERC
> is subject to the Freedom of Information Act 2000 and the contents
> of this email and any reply you make may be disclosed by NERC unless
> it is exempt from release under the Act. Any material supplied to
> NERC may be stored in an electronic records management system.
> 
> -- 
> MailScanner mailing list
> mailscanner at lists.mailscanner.info
> http://lists.mailscanner.info/mailman/listinfo/mailscanner
> 
> Before posting, read http://wiki.mailscanner.info/posting
> 
> Support MailScanner development - buy the book off the website! 
> 




-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/