On 04/06/2017 12:50 PM, George Kontostanos wrote:> On Thu, Apr 6, 2017 at 7:10 PM, Robert Moskowitz <rgm at htt-consult.com> wrote: >> It seems dovecot is impatient with connecting with mysql, as I see in >> maillog entries like: >> >> Apr 6 11:48:30 z9m9z dovecot: dict: Error: mysql(localhost): Connect failed >> to database (postfix): Can't connect to local MySQL server through socket >> '/var/lib/mysql/mysql.sock' (13) - waiting for 5 seconds before retry >> Apr 6 11:48:35 z9m9z dovecot: dict: Error: mysql(localhost): Connect failed >> to database (postfix): Can't connect to local MySQL server through socket >> '/var/lib/mysql/mysql.sock' (13) - waiting for 25 seconds before retry >> >> I suspect it does connect eventually. This is a test system with only 1GB >> of memory and free reports: >> >> total used free shared buff/cache available >> Mem: 1025484 696344 24556 21528 304584 251552 >> Swap: 524284 92168 432116 >> >> >> The production box has 2GB, so if the problem is mysql is swapping out, that >> will be 'fixed', if it is processor, well this is an ARMv7 duo core, as is >> the production box. I am considering buying the new quad core. >> >> Is there anything I can do to get dovecot more patient with mysql, or just >> ignore there messages? >> >> thank you > I really don't understand how you reached to the conclusion that > dovecot is impatient.Well, it waits a varying amount of time before reporting the connection failed. Not a fixed amount of time. Why mysql takes so long to connect via a sock is separate, but I suspect it is the low memory and duo core limitations. Maybe the question is more what is mysql not doing to take so long to respond to the connection.
Oh, that time is an exponential backoff on mysql not responding. So where is the time dovecot waits before backing off configured? On 04/06/2017 01:04 PM, Robert Moskowitz wrote:> > > On 04/06/2017 12:50 PM, George Kontostanos wrote: >> On Thu, Apr 6, 2017 at 7:10 PM, Robert Moskowitz >> <rgm at htt-consult.com> wrote: >>> It seems dovecot is impatient with connecting with mysql, as I see in >>> maillog entries like: >>> >>> Apr 6 11:48:30 z9m9z dovecot: dict: Error: mysql(localhost): >>> Connect failed >>> to database (postfix): Can't connect to local MySQL server through >>> socket >>> '/var/lib/mysql/mysql.sock' (13) - waiting for 5 seconds before retry >>> Apr 6 11:48:35 z9m9z dovecot: dict: Error: mysql(localhost): >>> Connect failed >>> to database (postfix): Can't connect to local MySQL server through >>> socket >>> '/var/lib/mysql/mysql.sock' (13) - waiting for 25 seconds before retry >>> >>> I suspect it does connect eventually. This is a test system with >>> only 1GB >>> of memory and free reports: >>> >>> total used free shared buff/cache >>> available >>> Mem: 1025484 696344 24556 21528 304584 251552 >>> Swap: 524284 92168 432116 >>> >>> >>> The production box has 2GB, so if the problem is mysql is swapping >>> out, that >>> will be 'fixed', if it is processor, well this is an ARMv7 duo core, >>> as is >>> the production box. I am considering buying the new quad core. >>> >>> Is there anything I can do to get dovecot more patient with mysql, >>> or just >>> ignore there messages? >>> >>> thank you >> I really don't understand how you reached to the conclusion that >> dovecot is impatient. > > Well, it waits a varying amount of time before reporting the > connection failed. Not a fixed amount of time. > > Why mysql takes so long to connect via a sock is separate, but I > suspect it is the low memory and duo core limitations. > > Maybe the question is more what is mysql not doing to take so long to > respond to the connection. >
On 6 Apr 2017, at 20.37, Robert Moskowitz <rgm at htt-consult.com> wrote:> > Oh, that time is an exponential backoff on mysql not responding. > > So where is the time dovecot waits before backing off configured?Looks like these were missing from the example dovecot-sql.conf.ext: # connect_timeout - Connect timeout in seconds (default: 5) # read_timeout - Read timeout in seconds (default: 30) # write_timeout - Write timeout in seconds (default: 30) So e.g.: connect = ... connect_timeout=30