Milter-greylist

manu@... wrote:
> Chris Hoogendyk <hoogendyk@...> wrote:
>
>   
>> so, would stack or number of files seem to be a problem from 
>> milter-greylist's point of view?
>>     
>
> You can always unlimit them to check if there is a change.
>
> Could you run milter-greylist within gdb and collect a backtrace at
> crash time? That would help
>
> # gdb milter-greylist
> (gdb) run -Dv
>
> when it crashes, run the bt command.
>   

ok, so I have two options here:

one is aimed at possibly solving my problem directly without answering 
why it's happening. That would be to add `ulimit -n unlimit` to the 
/etc/init.d/greylist startup script. Maybe it would solve the problem. 
Maybe it wouldn't.

the other option is to run milter-greylist from within the gnu debugger 
and wait for it to crash. this would contribute more in terms of 
figuring out why it's happening.

Please note that this is a departmental production server handling a 
large volume of mail. If I'm playing around and cause milter-greylist 
not to function for the better part of a day, there will be hundreds of 
users pissed at me for letting all that spam come flying through. So, 
with that in mind, . . . .

If I'm to run milter-greylist under gdb, I will have to run it from a 
terminal session. Fortunately, my desktop machine is on an APC 
Smart-UPS, and it is BSD based. So, typically, my desktop machine is up 
and running for months at a time with terminal sessions opened from one 
patch rev to the next (that typically being when I have to reboot). 
However, this means that my machine becomes semi-critical rather than 
just my tool. I may have to wait a week or a month for a crash of 
milter-greylist. Fortunately, again, I do have the fallback cron script 
on the server that will re-start milter-greylist if/when it crashes. But 
then, it will be running without a terminal session or a debugger. So, . 
. . .

I open a terminal session to the server, source the first half of the 
/etc/init.d/greylist to get the environment variables set:

     #! /bin/sh

     # Greylist init script
     # July 2004
     # BERTRAND Joel

     LD_LIBRARY_PATH=/usr/local/BerkeleyDB.4.4/lib;
     export LD_LIBRARY_PATH;

     # Based on skeleton by Miquel van Smoorenburg and Ian Murdock

     PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin
     DAEMON=/usr/local/bin/milter-greylist
     NAME=milter-greylist
     SNAME=greylist
     DESC="Greylist Mail Filter Daemon"
     PIDFILE="/var/run/$NAME.pid"
     PNAME="milter-greylist"
     USER="smmsp"
     #USER="root"
     CONFILE=/etc/mail/greylist.conf
     #SOCKET=/var/run/milter-greylist/greylist.sock
     SOCKET=/var/milter-greylist/greylist.sock
     POPIPDB=/etc/mail/popip.db
     # This is standard...
     DOPTIONS="-b $POPIPDB -P $PIDFILE -u $USER -p $SOCKET"
     # This is for debug...
     #DOPTIONS="-v -b $POPIPDB -P $PIDFILE -u $USER -p $SOCKET"

     TMPDIR=/tmp;
     export TMPDIR;
     # Apparently people have trouble if this isn't explicitly set...


and then

# dbg $DAEMON $DOPTIONS
(dbg) run -Dv

wait until I get a crash, and then

(dbg) backtrace

and send you the output


I'm assuming that if it crashes during the night, and the cron script 
restarts it on the server, my state within the debugger will remain 
unaltered and I will be able to do the backtrace.

And, while that is running, it will behave just like milter-greylist 
running off the init scripts free of any terminal sessions.

If that last sentence is true, then I can try this.



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

Chris Hoogendyk

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

<hoogendyk@...>

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

Erd\ufffds 4