Could not connect to socket /var/imap/socket/lmtp: Connection refused by localhost

Andy Dorman adorman at ironicdesign.com
Tue Jan 17 09:09:00 EST 2017


On 01/17/2017 05:21 AM, Eugene M. Zheganin via Info-cyrus wrote:
> Hi,
>
> I'm using cyrus-imapd for quite long, but recently I encountered an
> issue with delivery: one of my mail servers is handling a significant
> load of e-mails, and quite often I'm seeing line like this in the maillog:
>
> Jan 17 12:35:26 gw0 sm-mta[78888]: v0H7ZML4078586: SYSERR(root): Could
> not connect to socket /var/imap/socket/lmtp: Connection refused by localhost
>
> This usually means that message bounced to MTA queue, where it can be
> hold for several minutes, sometimes dozens of minutes. I have the
> following directive in the cyrus.conf:
>
> SERVICES {
>     ...
>     lmtp cmd="lmtpd" listen="localhost:lmtp" prefork=4 maxchild=16
>     lmtpunix cmd="lmtpd" listen="/var/imap/socket/lmtp" prefork=4
> maxchild=16 maxfds=2048
> }
>
> I discovered that simply increasing this value can make the situation
> even worse. Is there some decent aproach to increase the performance of
> lmtp ?
>
> Thanks.
> Eugene.
>

I am not an expert by any means and I hope someone corrects me if I make 
a bad suggestion...but I have two questions:

1. It sounds like you have a heavily used server, so why do you have 
Cyrus listening on both "localhost:lmtp" AND a unix socket 
"/var/imap/socket/lmtp"?

 From the log entry it looks like your MTA uses a unix socket.  Unless 
you have something else (mail clients or other MTAs running on your 
Cyrus server?) that need to communicate via the localhost:lmtp port, you 
could comment out the unneeded lmtp service line and save those resources.

2. You say "increasing this value can make the situation even worse". 
Which value?  There are 5 values on those two lines that you could 
increase.  And by "even worse" do you mean even more refused connections?

While I am not a Cyrus guru, I have seen my share of overloaded mail 
servers and if you are running into a disk IO limit, adding more 
processes fighting over a limited resource is very likely to make things 
worse.  So you should also confirm a hardware limitation is not at play 
here.

Sincere regards,

-- 
Andy Dorman



More information about the Info-cyrus mailing list