Yahoo Groups archive

Milter-greylist

Index last updated: 2026-04-28 23:32 UTC

Message

Re: [milter-greylist] [Fwd: watch-greylist]

2006-08-02 by Chris Hoogendyk

Matthias Scheler wrote:
> On Wed, Aug 02, 2006 at 12:23:10PM -0400, Chris Hoogendyk wrote:
>   
>> We are running milter-greylist-1.6 on Solaris 9 with Sendmail 8.13.6,
>> etc. on an E250 with dual sparc processors.
>>
>> We didn't go to milter-greylist-2.0.2 when building the system, because
>> we experienced what appeared to be memory leaks when trying to run it.
>> These seem to be in 1.6, but seemed to be worse in 2.0.2.
>>     
>
> Are you sure this is not a Solaris bug? Quoting from an e-mail which
> somebody sent to this list a while ago:
>
> 	Ok, I found the problem. Milter-greylist is innocent. It's a Solaris 
> 	bug. Solaris 8 needs the 108827-40 patch (which has since then been 
> 	obsoleted by 108993-39). There seem to be severe leaks in
> 	getaddrinfo() and friends in non-patched libpthread/libsocket/libnsl.
>
> Solaris 9 might require a similar patch.
>   

I'm not sure if it represents the same problem, but patch 112839 on
Solaris 9 applies to the same library components. It's current rev is 8.
Typically, Solaris 8 & 9 are rather different in a lot of ways, so I
wouldn't necessarily expect a bug in 8 on a component that had gone
through 40 patches to have the same history on 9. In any case, my system
has been patched.

If that were the problem, wouldn't I expect to see this cropping up in a
lot of other places? I'm running Sendmail, mimedefang, spamassassin,
milter-greylist, poprelayd, uw-imap, procmail, sasl-authd, samba, apache
2, php, squirrelmail, mysql, msql, berkeleydb, majordomo, hypermail,
tikiwiki, pro-ftp, netatalk, jetdirect, as well as all the development
tools. The server processes over 50,000 mail messages a day and has 24
drives hanging off it for research space, web space and data.

I don't want to put down milter-greylist, because it is a godsend for
reducing spam. But, it is the only process that I have to have watched
by a cron to make sure it stays up.

We have milter-greylist running on a couple of other systems. One is 
nearly identical, but doesn't serve as large a volume of mail. It
experiences failures of milter-greylist less frequently. The other is an
OpenBSD system on a PC that serves a small office. It has never
experienced failures. One aspect of this comparison is that the OpenBSD
system handles probably 1/100th of the mail volume. Another aspect is
that it is a single processor system. Both of the Sun servers are dual
processor. This comparison could indicate that the problem accumulates
over volume of processing, and/or that it is in some way not thread safe
on a multiprocessor system. But that's guessing.

>> If it can see that it has gone "to error state", why shouldn't it just
>> terminate on the spot? Does it think it will come out of error state?
>>     
>
> The "error state" message is printed out by "sendmail", not by
> "milter-greylist".
>
> 	Kind regards
>   

---------------

Chris Hoogendyk

-
   O__  ---- Systems Administrator
  c/ /'_ --- Biology & Geology Departments
 (*) \(*) -- 140 Morrill Science Center
~~~~~~~~~~ - University of Massachusetts, Amherst 

<hoogendyk@...>

--------------- 

Erd\ufffds 4

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.