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 <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
-- ## List details at http://www.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://www.exim.org/eximwiki/
