* * * * *
                                        
 And I thought I was being extravagant for using 20 megabytes for the greylist
                                     daemon
                                        
As if the problems I'm having getting the greylist daemon [1] 64-bit clean
and less Linux-centric [2] weren't bad enough, today I find that the Sendmail
[3] client just stopped working. I checked the logs, and sure enough, the
milter library [4] is bitching up a storm:

> Oct 31 17:32:08 XXXX smgl: Greylist Daemon: thread_create() failed: 12, try again
> Oct 31 17:32:44 XXXX last message repeated 5 times
> Oct 31 17:33:13 XXXX last message repeated 10 times
> Oct 31 17:33:17 XXXX smgl: Greylist Daemon, mi_rd_cmd: read returned -1: Connection reset by peer
> Oct 31 17:33:17 XXXX smgl: Greylist Daemon, mi_rd_cmd: read returned -1: Connection reset by peer
> Oct 31 17:33:17 XXXX smgl: Greylist Daemon: thread_create() failed: 12, try again
> Oct 31 17:33:50 XXXX last message repeated 13 times
> Oct 31 17:34:52 XXXX last message repeated 28 times
> Oct 31 17:35:54 XXXX last message repeated 34 times
> Oct 31 17:37:02 XXXX last message repeated 21 times
> Oct 31 17:38:05 XXXX last message repeated 7 times
> Oct 31 17:39:11 XXXX last message repeated 16 times
> Oct 31 17:40:20 XXXX last message repeated 7 times
> Oct 31 17:41:31 XXXX last message repeated 8 times
> Oct 31 17:41:50 XXXX smgl: Greylist Daemon: thread_create() failed: 12, try again
> Nov  1 12:22:53 XXXX smgl: Address: 127.0.0.1:0
> Nov  2 19:25:21 XXXX smgl: Greylist Daemon: mi_stop=1
> Nov  2 19:27:56 XXXX smc: Address: 0.0.0.0:0
> 

Okay. That mi_stop=1 doesn't look good; let me see what I can find out about
that:

> On Tue, 27 Jul 2004, Matt Selsky wrote:
> 
> > Jul 27 09:12:20 clover mimedefang[22489]: [ID 649295 mail.info]
> > MIMEDefang-2.44: mi_stop=1
> > 
> 
> This is normal.
> 
> Regards,
> 
> David.
> 

“[Mimedefang] mi_stop=1 message in syslog [5]”

Lovely! Not only is it normal, but the only reference I found was dated 2004!

There was nothing at all about mi_rd_cmd returning -1, but I did find the
following about the thread_create() failed: 12:

> On Thu, 28 Oct 2004, Stephane Lentz wrote:
> 
> > PS: a folk running Linux reported a similar problem but he's not runing
> > RH (Redhat). On Mandrake/SuSE I've never seen it. How much traffic do you
> > process ? Which hardware ? Try to get some recommendations on system
> > tuning from RH since you're paying $$$$ .
> > 
> 
> Here's some free advice: On RHEL (Redhat Enterprise Linux)3, type “ulimit -
> s”:
> 
> > $ ulimit -s
> > 10240
> > 
> 
> So each thread wants 10MB (Megabyte) of stack space. That can chew up your
> RAM (Random Access Memory) pretty quickly. I recommend editing the
> MIMEDefang startup script and putting:
> 
> > ulimit -s 2048
> > 
> 
> just before mimedefang (not the multiplexor!) is invoked.
> 
> Right now, the sample red hat script does it only if you have more than 100
> slaves, but it should really do it unconditionally.
> 
> Regards,
> 
> David.
> 

“[Mimedefang] thread_create errors [6]”

Sweet Jesus! No wonder the Sendmail client sucks up memory like there's no
tomorrow! Sheesh!

[1] gopher://gopher.conman.org/0Phlog:2007/08/16.1
[2] gopher://gopher.conman.org/0Phlog:2007/11/04.1
[3] http://www.sendmail.org/
[4] https://www.milter.org/developers
[5] http://lists.roaringpenguin.com/pipermail/mimedefang/2004-
[6] http://lists.roaringpenguin.com/pipermail/mimedefang/2004-

Email Sean Conner at sean@conman.org

.