Yes, the "idle-timeout-secs" command would be best. My own server is
set to 60, though 180 seems to be common among configuration files I've
seen here on the list. Really, _anything_ is good as long as it's set,
so that the connection eventually be closed if there's no activity. By
default, qmail will disconnect after 20 minutes of inactivity but if
spamdyke has already terminated qmail (because the connection has been
rejected), that timeout will never occur.
The number of RBL entries you can use depends greatly on your own
installation. Your level of incoming mail traffic, your available
bandwidth, the speed of your DNS servers, etc. Personally, I believe
the popular anti-spam RBLs (like Spamhaus) list mostly the same IP
addresses, so more is not necessarily better. In your case, where it
appears your DNS server is being overwhelmed, more is definitely not
better. :)
To figure out what a running process is doing, you have two choices.
The most commonly available option is strace. To use it, find the PID
of a running spamdyke process and use this command:
strace -t -p PID
For running processes that aren't stuck, strace is the best option. It
will print output as long as the process is running (or until you hit
CTRL-C). If the process is blocked, you'll just get one line of output
showing where it's stuck and that's it.
If the process is blocked on one function call, the other option is to
use gdb. For this method to be useful, the binary must be compiled with
debugging symbols. In the case of spamdyke, you can do that by running
the "configure" command with the "--with-debug-symbols" flag, running
"make" again, then replacing the old spamdyke binary with the new one.
Once spamdyke is running with debug symbols, find the PID of a running
spamdyke process and use this command:
gdb /usr/local/bin/spamdyke
> attach PID
> where
You should get a stack trace showing what spamdyke is waiting for and
exactly what code was called to reach that point. Running spamdyke with
debugging symbols doesn't hurt anything, it just makes the binary a
little bigger. Also, this technique is really only effective when
spamdyke is stuck because it must stop spamdyke's execution in order to
attach the debugger. If spamdyke is looping for some reason, gdb won't
show it.
It's hard to say what a "normal" number of spamdyke processes is -- as I
said before, it depends on your setup. I don't really think it matters
how many are running as long as mail is being delivered and none of the
processes refuse to exit.
-- Sam Clippinger
Matthew Kettlewell wrote:
> Sam, Thanks for the info... comments inline below.
>
>
>>> Your configuration file
>>> doesn't include a timeout command,
>>>
> Would this be the idle-timeout-secs ? I've now set it to 240, what range
> of values should I consider experimenting with?
>
>
>>> For starters, you could try setting the "dns-level" option to "normal"
>>>
> Done
>
>>> You could also try removing some of the RBL entries from
>>> your configuration file so there will be less DNS work to perform.
>>>
>>>
> I slimmed it down to 4 ... Is this still overkill?
>
>>> Tools like strace and gdb might shed some light on what they're doing (or
>>> waiting for).
>>>
>>>
> Is there a particular command that I can run on a PID that gets you the
> most useful information? I imagine that strace is similar to truss (on
> Solaris) but I don't know the CL arguments to give it.
>
>
> Thanks for all the help and tips.... I've been monitoring my processes
> and I'm fluctuating between 5 and 15 spamdyke processes at any given
> time, which appears normal to me ( but I'm an absolute mail dunce)
>
> Matt
>
>
>
> _______________________________________________
> spamdyke-users mailing list
> [email protected]
> http://www.spamdyke.org/mailman/listinfo/spamdyke-users
>
_______________________________________________
spamdyke-users mailing list
[email protected]
http://www.spamdyke.org/mailman/listinfo/spamdyke-users
