idled vs poll

[Adam Stephens]

Scott Adkins wrote:
>
>>> cannot connect to saslauthd server: Connection refused
>>> Failed to connect to socket /var/cyrus/imap/socket/lmtp for
>>>        local_cyrus_deliver
>>> transport: Connection refused
>>> error sending to idled: 0
>
> The first thing I would do here is to use LMTP as a TCP socket instead of
> a UNIX domain socket.  We use Tru64 in our environment, and when I first
> deployed Cyrus under that architecture, the first thing I noticed what 
> that
> as load increased, the more "connection refused" messages I saw with 
> LMTP.
> Pointing my MTA to a TCP LMTP socket completely eliminated that 
> problem for
> us.  However, you should still keep the UNIX socket, since the "deliver"
> program still uses that instead of the TCP socket (the last time I 
> checked).
>
> Additionally, when setting up the TCP socket, it would be good to set 
> it to
> listen only on localhost or a private address (to prevent Internet users
> from connecting to your LMTP server and bypassing your MTA and spam/virus
> filtering controls).  It is either that, or you configure authentication
> for the LMTP server (which, admittedly, I have never done).
>
> For SASL, I don't know if there can be any changes there.  We use UNIX
> sockets for it as well, and I haven't investigated to see if there is a
> TCP socket option.  That might help if there is one.  On our system, when
> I see load increase, I definitely see SASL authentication take longer as
> well.  We have worked most of our load problems out (Tru64 related), so
> that has improved considerably.  We use the "poll" method, not "idled".
>
> Good luck. 
Thanks for those suggestions.

We managed to mitigate the SASL problem by running it as a real-time 
process, which at least allowed people to log in; it's also been 
suggested that, since we're on Solaris, rebuilding it to use RPC doors 
instead might help. And I suppose we might be able to work around the 
other symptoms as well - but the stress placed on the system is so 
disproportionate to the advantage gained from idled that the obvious 
thing to do (which we've done) is to switch back to the poll method; we 
don't see any socket errors at all with idled disabled, and the system 
load is trivial.

regards,
Adam.
-- 
--------------------------------
Adam Stephens
Network Specialist - Email & DNS
adam.stephens at bristol.ac.uk