Re: Getting greylisting going on a new Debian

It was thus said that the Great Jose-Marcio Martins da Cruz once stated:
> Sean Conner wrote:
> >It was thus said that the Great Jose-Marcio Martins da Cruz once stated:
> >>Sean Conner wrote:
> ...
> >>Hmmm. Threads under linux ... They eat memory. Other OSs (Solaris, 
> >>FreeBSD) do it better.
> >
> >  Tracking that down took quite a bit of investigation and it involved a
> >trip through the source code for pthreads under Linux.
> 
> Not really... 8-)
> 
> In a Linux box, look for clone(2) - all you need to know is there :
> 
> 	man clone

  Ah, if only.  Normally, the stack space for a process (not a thread) is
allocated dynamically as the system runs---fill up a page in the stack, a
segfault, the system then knows to allocate another page or two to the
stack.  The fact that I have a 10M limit on the stack doesn't mean it
actually *takes* 10M of space.

  Unfortunately, the pthread initialization code (which is run *before*
main() is called) checks setrlimit() for the maximum stack size.  Then, each
time a thread is created, it allocates said amount, which wouldn't be all
that bad (since Linux uses overcommit---it basically creates enough entries
in the page tables for the memory without actually allocating the memory)
except that pthreads then *clears* the freshly allocated memory.  That
unfortunately, touches the memory, causing the system to *physically*
allocate the memory.

> >  Well, I basically ended up doing a "ulimit -s" [1] and that seems to have
> >sovled for the most part the memory issues (did have to keep tweaking the
> >value between "uses too much" and "too little it crashes").
> 
> 	man ulimit
> 
>        ulimit [-SHacdefilmnpqrstuvx [limit]]
>               Provides control over the resources available to the  shell  
>               and
>               to  processes started by it, on systems that allow such 
>               control.
>                   ^^^^^^^^^
>               The -H and -S options specify that the hard or soft limit is 
>               set
> 
>               ...
> 
>               -s     The maximum stack size
> 
> 	I understant : "the maximum stack size per process." Am I right ???

  Yup.

> >  -spc (Wishes we could use Postfix at The Office though ... )
> 
> Sorry but, IMHO, the problem here isn't sendmail, but linux threads.

  The problem *is* sendmail, or at least, the milter library, which is a
part of sendmail, using pthreads when (personally) I don't see the actual
need for it (for instance, the Postfix interface doesn't require threading).

  -spc (And if the protocol used between sendmail and milter were
	documented, I would scrap the use of milter entirely, but alas,
	the protocol isn't documented, and *that* fact *is* documented)