Re: [exim] timing out messages in the queue

On Wed, 2007-07-04 at 18:28 -0400, David S. Madole wrote:
> > From Ron Gorodetzky on Wednesday, July 04, 2007 4:58 PM
> >
> > I have two servers that use a third as a smarthost for
> > outbound emails.
> > On the smarthost I'm seeing those outbound messages getting
> > stuck in the queue in a 'waiting for a remote delivery
> > subprocess to finish' state, seemingly forever. This holds
> > up other messages from being sent out and adds unwanted
> > process load to the server. Is there a way to get these to
> > timeout more quickly so that the queue can make some progress?
> >
> > I tried adding command_timeout = 20s in the remote_smtp:
> > section, but it doesn't seem to have an effect. It wasn't
> > clear to me from the documentation what other options I have
> > to resolve this problem.
>
> Also take a look at connect_timeout, data_timeout, and final_timeout.
>

I've never really had the need to tweak default settings too much though
after investigating a bit more, I'm not sure why not. I'm going to have
to reevaluate my other setups.

These are the settings I've chosen for timeouts. Are they too
ambitious?
command_timeout = 20s
connect_timeout = 20s
data_timeout = 30s
final_timeout = 1m


> It might help to run a delivery of one of the problem messages from the command line with debugging output to see what is happening, use exim -d -M <message-id>
>

This was actually the best advice, since I apparently had a mental block
towards running exim with debug output.

I found that at least one of the misbehaving messages was hanging on the
following:

initializing GnuTLS as a client
generating 512 bit RSA key...
selecting on subprocess pipes
selecting on subprocess pipes
...

After searching a bit online, some said to make sure (on debian) gnutls
was installed, or to make sure you don't have entropy starvation,
pregenerating exim.key and exim.crt files, etc. Nothing seemed to make
any difference. So I decided to just turn off tls for remote_smtp. Like
so:

hosts_avoid_tls = *

That seemed to do the trick. I'm not entirely sure why the other
supposed fixes didn't work. I certainly support the use of tls (I use
it for smtp between client apps when I setup a mail server with
authentication) so it feels odd turning it off. Is it common practice
to leave it on for server to server mail exchange? Should I expect a
lot of rejected mail using this setting?

> I don't know what you mean by seemingly forever; the longest of these timeouts is 10 minutes by default. If you are seeing longer than that, then something else is wrong. Perhaps you are delivering to a "tar pit".
>

Well, heh, yeah, in this fast paced web 2.0 world 10 minutes is
basically forever. The problem with messages taking 10 minutes to
timeout was that it held up the queue. I adjusted parameters to startup
new queues more often and such, but no matter what I tried I'd
eventually get thousands exim process waiting to relay their messages.
So, there may be another way around the slow message delivery pileup but
it seems that avoiding the slow message delivery all together is a
better solution.

Thanks again,

-Ron

--
Ron Gorodetzky <ron@???>