Am 15.02.2012 20:10, schrieb Robert Schetterer:
> Am 15.02.2012 19:43, schrieb Timo Sirainen:
>> On 15.2.2012, at 20.22, Robert Schetterer wrote:
>>
>>> sorry for some more question
>>> what is the default behave if dict quota over sql cant be reached
>>> i.e with lmtp
>>>
>>> something like log wa
Am 15.02.2012 19:43, schrieb Timo Sirainen:
> On 15.2.2012, at 20.22, Robert Schetterer wrote:
>
>> sorry for some more question
>> what is the default behave if dict quota over sql cant be reached
>> i.e with lmtp
>>
>> something like log warning and deliver anyway ?
>
> I think it tempfails. Tr
On 15.2.2012, at 20.22, Robert Schetterer wrote:
> sorry for some more question
> what is the default behave if dict quota over sql cant be reached
> i.e with lmtp
>
> something like log warning and deliver anyway ?
I think it tempfails. Try.
Am 15.02.2012 17:10, schrieb Robert Schetterer:
> Am 15.02.2012 14:07, schrieb Timo Sirainen:
>> On Wed, 2012-02-15 at 09:10 +0100, Robert Schetterer wrote:
>>> Hi Timo,just to make sure
>>> i have an extra
>>> dovecot-dict-quota-sql.conf.ext ( dove 2.0.18 )
>>>
>>> connect = host=192.168.123.150 d
Am 15.02.2012 14:07, schrieb Timo Sirainen:
> On Wed, 2012-02-15 at 09:10 +0100, Robert Schetterer wrote:
>> Hi Timo,just to make sure
>> i have an extra
>> dovecot-dict-quota-sql.conf.ext ( dove 2.0.18 )
>>
>> connect = host=192.168.123.150 dbname=.. user=... password=...
> ..
>> is it possible to
On Wed, 2012-02-15 at 09:10 +0100, Robert Schetterer wrote:
> Hi Timo,just to make sure
> i have an extra
> dovecot-dict-quota-sql.conf.ext ( dove 2.0.18 )
>
> connect = host=192.168.123.150 dbname=.. user=... password=...
..
> is it possible to have i.e
>
> connect = host=192.168.123.150 host=12
Am 28.01.2012 22:06, schrieb Robert Schetterer:
> Am 28.01.2012 21:07, schrieb Timo Sirainen:
>> On 13.1.2012, at 20.29, Mark Moseley wrote:
>>
>>> If there are multiple hosts, it seems like the most robust thing to do
>>> would be to exhaust the existing connections and if none of those
>>> succee
On Sat, Jan 28, 2012 at 12:07 PM, Timo Sirainen wrote:
> On 13.1.2012, at 20.29, Mark Moseley wrote:
>
>> If there are multiple hosts, it seems like the most robust thing to do
>> would be to exhaust the existing connections and if none of those
>> succeed, then start a new connection to one of th
Am 28.01.2012 23:17, schrieb Timo Sirainen:
> On 28.1.2012, at 23.06, Robert Schetterer wrote:
>
>> doc/example-config/dovecot-sql.conf.ext
>> from hg
>> has something like
>>
>> # Database connection string. This is driver-specific setting.
>> # HA / round-robin load-balancing is supported by giv
On 28.1.2012, at 23.06, Robert Schetterer wrote:
> doc/example-config/dovecot-sql.conf.ext
> from hg
> has something like
>
> # Database connection string. This is driver-specific setting.
> # HA / round-robin load-balancing is supported by giving multiple host
> # settings, like: host=sql1.host.
Am 28.01.2012 21:07, schrieb Timo Sirainen:
> On 13.1.2012, at 20.29, Mark Moseley wrote:
>
>> If there are multiple hosts, it seems like the most robust thing to do
>> would be to exhaust the existing connections and if none of those
>> succeed, then start a new connection to one of them. It will
On 13.1.2012, at 20.29, Mark Moseley wrote:
> If there are multiple hosts, it seems like the most robust thing to do
> would be to exhaust the existing connections and if none of those
> succeed, then start a new connection to one of them. It will probably
> result in much more convoluted logic bu
On Fri, Jan 20, 2012 at 09:16:57AM -0800, Timo Sirainen wrote:
> This is fixed in v2.1 hg. The default idle_kill of 60 seconds seems to
> have gotten rid of the "MySQL server has gone away" errors completely.
> So I guess the problem was that during some peak times a ton of auth
> worker processes
On 1/20/2012 9:17 AM, Timo Sirainen wrote:
Works for me. Are you maybe sending it to wrong auth process (auth worker
instead of master)?
I had tried sending it to both; but the underlying problem turned out to
be that the updated config hadn't actually been deployed yet 8-/ oops.
Once I fix
On 1/20/2012 1:06 PM, Timo Sirainen wrote:
Hmh. Still doesn't work 100%:
auth-worker(28788): Error: mysql: Query failed, retrying: MySQL
server has gone away (idled for 181 secs) auth-worker(7413): Error:
mysql: Query failed, retrying: MySQL server has gone away (idled for
298 secs)
I'm not re
On 20.1.2012, at 19.16, Timo Sirainen wrote:
> This is fixed in v2.1 hg. The default idle_kill of 60 seconds seems to have
> gotten rid of the "MySQL server has gone away" errors completely. So I guess
> the problem was that during some peak times a ton of auth worker processes
> were created,
On 14.1.2012, at 2.19, Paul B. Henson wrote:
> On Fri, Jan 13, 2012 at 11:38:28AM -0800, Robert Schetterer wrote:
>
>> by the way , if you use sql for auth have you tried auth caching ?
>>
>> http://wiki.dovecot.org/Authentication/Caching
>
> That page says you can send a USR2 signal to the aut
On 14.1.2012, at 1.19, Mark Moseley wrote:
>>> Also another idea to avoid them in the first place:
>>>
>>> service auth-worker {
>>> idle_kill = 20
>>> }
>>
>> Ah, set the auth-worker timeout to less than the mysql timeout to
>> prevent a stale mysql connection from ever being used. I'll try t
On Sat, Jan 14, 2012 at 12:01:12AM -0800, Robert Schetterer wrote:
> > Hmm, hadn't tried that, but flipped it on to see how it might work out.
> > The only tradeoff is a potential delay between when an account is
> > disabled and when it can stop authenticating. I set the timeout to 10
> > minutes
Am 14.01.2012 01:19, schrieb Paul B. Henson:
> On Fri, Jan 13, 2012 at 11:38:28AM -0800, Robert Schetterer wrote:
>
>> by the way , if you use sql for auth have you tried auth caching ?
>>
>> http://wiki.dovecot.org/Authentication/Caching
>
> Hmm, hadn't tried that, but flipped it on to see how i
On 1/13/2012 10:29 AM, Mark Moseley wrote:
connection prior to this, is the auth worker not recognizing its
connection is already half-closed (in which case, it probably
shouldn't even consider it a legitimate connection and just
automatically reconnect, i.e. try #1, not the retry, which would
h
On Fri, Jan 13, 2012 at 11:38:28AM -0800, Robert Schetterer wrote:
> by the way , if you use sql for auth have you tried auth caching ?
>
> http://wiki.dovecot.org/Authentication/Caching
Hmm, hadn't tried that, but flipped it on to see how it might work out.
The only tradeoff is a potential dela
On Fri, Jan 13, 2012 at 2:46 PM, Paul B. Henson wrote:
> On Fri, Jan 13, 2012 at 01:36:38AM -0800, Timo Sirainen wrote:
>
>> Also another idea to avoid them in the first place:
>>
>> service auth-worker {
>> idle_kill = 20
>> }
>
> Ah, set the auth-worker timeout to less than the mysql timeout t
On Fri, Jan 13, 2012 at 01:36:38AM -0800, Timo Sirainen wrote:
> Also another idea to avoid them in the first place:
>
> service auth-worker {
> idle_kill = 20
> }
Ah, set the auth-worker timeout to less than the mysql timeout to
prevent a stale mysql connection from ever being used. I'll try
On Fri, Jan 13, 2012 at 11:38 AM, Robert Schetterer
wrote:
> Am 13.01.2012 19:29, schrieb Mark Moseley:
>> On Fri, Jan 13, 2012 at 1:36 AM, Timo Sirainen wrote:
>>> On 13.1.2012, at 4.00, Mark Moseley wrote:
>>>
I'm running 2.0.17 and I'm still seeing a decent amount of "MySQL
server ha
Am 13.01.2012 19:29, schrieb Mark Moseley:
> On Fri, Jan 13, 2012 at 1:36 AM, Timo Sirainen wrote:
>> On 13.1.2012, at 4.00, Mark Moseley wrote:
>>
>>> I'm running 2.0.17 and I'm still seeing a decent amount of "MySQL
>>> server has gone away" errors, despite having multiple hosts defined in
>>> m
On Fri, Jan 13, 2012 at 1:36 AM, Timo Sirainen wrote:
> On 13.1.2012, at 4.00, Mark Moseley wrote:
>
>> I'm running 2.0.17 and I'm still seeing a decent amount of "MySQL
>> server has gone away" errors, despite having multiple hosts defined in
>> my auth userdb 'connect'. This is Debian Lenny 32-b
On 13.1.2012, at 4.00, Mark Moseley wrote:
> I'm running 2.0.17 and I'm still seeing a decent amount of "MySQL
> server has gone away" errors, despite having multiple hosts defined in
> my auth userdb 'connect'. This is Debian Lenny 32-bit and I'm seeing
> the same thing with 2.0.16 on Debian Sque
On 1/12/2012 6:00 PM, Mark Moseley wrote:
Jan 12 20:30:33 auth-worker: Error: mysql: Query failed, retrying:
MySQL server has gone away
I've actually been meaning to send a similar message for the last couple
of months :).
We run dovecot solely as a sasl authentication provider to postfix f
I'm running 2.0.17 and I'm still seeing a decent amount of "MySQL
server has gone away" errors, despite having multiple hosts defined in
my auth userdb 'connect'. This is Debian Lenny 32-bit and I'm seeing
the same thing with 2.0.16 on Debian Squeeze 64-bit.
E.g.:
Jan 12 20:30:33 auth-worker: Err
30 matches
Mail list logo
