dovecot-2.3.2.1 and dovecot-pigeonhole-0.5.2 bug?

2018-09-07 Thread Jan Nowak 
Hello,

we have a problem after updating the software with the operation of sieve
scripts sending a copy of the e-mails, e-mails are not transferred.

Configuration:
dovecot-2.3.2.1 + dovecot-pigeonhole-0.5.2 + FreeBSD 11.2

log:
Sep 06 13:28:17 lda(XXX@XXX)<38615>: Info: sieve:
msgid=: stored mail into mailbox 'INBOX'
Sep 06 13:28:17 lda(XXX@XXX)<38615>: Info: sieve: Execution of
script /usr/home/XXX/mail/XXX@XXX/.dovecot.sieve failed, but implicit keep
was successful (user logfile /usr/home/XXX/mail/XXX@XXX/.dovecot.sieve.log
may reveal additional details)

.dovecot.sieve.log:
error: msgid=: failed to redirect message to
: smtp(127.0.0.1:25): DATA failed: 552 Message header not
CRLF terminated (permanent failure).


On old configuration:
dovecot 2.2 + dovecot-pigeonhole- 0.4  + FreeBSD 11.2
we don't have problem.

Has anyone had a similar problem, knows the solution?

Re: Auth process sometimes stop responding after upgrade

2018-09-07 Thread Timo Sirainen 
On 7 Sep 2018, at 19.43, Timo Sirainen  wrote:On 7 Sep 2018, at 16.50, Simone Lazzaris  wrote:Some more information: the issue has just occurred, again on an instance without the "service_count = 0" configuration directive on pop3-login. I've observed that while the issue is occurring, the director process goes 100% CPU. I've straced the process. It is seemingly looping: ..epoll_ctl(13, EPOLL_CTL_ADD, 78, {EPOLLIN|EPOLLPRI|EPOLLERR|EPOLLHUP, {u32=149035320, u64=149035320}}) = 0epoll_ctl(13, EPOLL_CTL_DEL, 78, {0, {u32=149035320, u64=149035320}}) = 0epoll_ctl(13, EPOLL_CTL_ADD, 78, {EPOLLIN|EPOLLPRI|EPOLLERR|EPOLLHUP, {u32=149035320, u64=149035320}}) = 0epoll_ctl(13, EPOLL_CTL_DEL, 78, {0, {u32=149035320, u64=149035320}}) = 0epoll_ctl(13, EPOLL_CTL_ADD, 78, {EPOLLIN|EPOLLPRI|EPOLLERR|EPOLLHUP, {u32=149035320, u64=149035320}}) = 0epoll_ctl(13, EPOLL_CTL_DEL, 78, {0, {u32=149035320, u64=149035320}}) = 0Nothing else but these epoll_ctl() calls? So it's gone to some loop where it keeps calling io_add() and io_remove(). I'm guessing it's because of doveadm command handling issues, since there's some weirdness in the code. Although I couldn't figure out exactly why it would go to infinite loop there. But attached a patch that may fix it, if you're able to test. We haven't noticed such infinite looping in other installations or automated director stresstests though..

2417.patch
Description: Binary data
FD 13 is "anon_inode:[eventpoll]"What about fd 78? I guess some socket.Could you also try two more things when it happens again:ltrace -tt -e '*' -o ltrace.log -p (My guess this isn't going to be very useful, but just in case it might be..)gdb -p bt fullquitPreferably install dovecot-dbg package also so the gdb backtrace output will be better.These would still be useful to verify whether I'm even on the right track.

Re: Auth process sometimes stop responding after upgrade

2018-09-07 Thread Timo Sirainen 
On 7 Sep 2018, at 16.50, Simone Lazzaris  wrote:
> 
> Some more information: the issue has just occurred, again on an instance 
> without the "service_count = 0" configuration directive on pop3-login.
>  
> I've observed that while the issue is occurring, the director process goes 
> 100% CPU. I've straced the process. It is seemingly looping:
>  
> ...
> ...
> epoll_ctl(13, EPOLL_CTL_ADD, 78, {EPOLLIN|EPOLLPRI|EPOLLERR|EPOLLHUP, 
> {u32=149035320, u64=149035320}}) = 0
> epoll_ctl(13, EPOLL_CTL_DEL, 78, {0, {u32=149035320, u64=149035320}}) = 0
> epoll_ctl(13, EPOLL_CTL_ADD, 78, {EPOLLIN|EPOLLPRI|EPOLLERR|EPOLLHUP, 
> {u32=149035320, u64=149035320}}) = 0
> epoll_ctl(13, EPOLL_CTL_DEL, 78, {0, {u32=149035320, u64=149035320}}) = 0
> epoll_ctl(13, EPOLL_CTL_ADD, 78, {EPOLLIN|EPOLLPRI|EPOLLERR|EPOLLHUP, 
> {u32=149035320, u64=149035320}}) = 0
> epoll_ctl(13, EPOLL_CTL_DEL, 78, {0, {u32=149035320, u64=149035320}}) = 0

Nothing else but these epoll_ctl() calls? So it's gone to some loop where it 
keeps calling io_add() and io_remove(). 

> FD 13 is "anon_inode:[eventpoll]"

What about fd 78? I guess some socket.

Could you also try two more things when it happens again:

ltrace -tt -e '*' -o ltrace.log -p 
(My guess this isn't going to be very useful, but just in case it might be..)

gdb -p 
bt full
quit

Preferably install dovecot-dbg package also so the gdb backtrace output will be 
better.

Sievescript in database

2018-09-07 Thread Harald Leithner 
Hi,

is it possible to save sieve scripts to a mysql database?

I know its possible to read them with the dict sql plugin but iirc it
wasn't possible to save it with sievemanaged.

thx

Harald

-- 
Harald Leithner

ITronic
Wiedner Hauptstraße 120/5.1, 1050 Wien, Austria
Tel: +43-1-545 0 604
Mobil: +43-699-123 78 4 78
Mail: leith...@itronic.at | itronic.at



signature.asc
Description: OpenPGP digital signature

Re: Auth process sometimes stop responding after upgrade

2018-09-07 Thread Simone Lazzaris 
Some more information: the issue has just occurred, again on an instance 
without the 
"service_count = 0" configuration directive on pop3-login.

I've observed that while the issue is occurring, the director process goes 100% 
CPU. I've 
straced the process. It is seemingly looping:

...
...
epoll_ctl(13, EPOLL_CTL_ADD, 78, {EPOLLIN|EPOLLPRI|EPOLLERR|EPOLLHUP, 
{u32=149035320, u64=149035320}}) = 0
epoll_ctl(13, EPOLL_CTL_DEL, 78, {0, {u32=149035320, u64=149035320}}) = 0
epoll_ctl(13, EPOLL_CTL_ADD, 78, {EPOLLIN|EPOLLPRI|EPOLLERR|EPOLLHUP, 
{u32=149035320, u64=149035320}}) = 0
epoll_ctl(13, EPOLL_CTL_DEL, 78, {0, {u32=149035320, u64=149035320}}) = 0
epoll_ctl(13, EPOLL_CTL_ADD, 78, {EPOLLIN|EPOLLPRI|EPOLLERR|EPOLLHUP, 
{u32=149035320, u64=149035320}}) = 0
epoll_ctl(13, EPOLL_CTL_DEL, 78, {0, {u32=149035320, u64=149035320}}) = 0
epoll_ctl(13, EPOLL_CTL_ADD, 78, {EPOLLIN|EPOLLPRI|EPOLLERR|EPOLLHUP, 
{u32=149035320, u64=149035320}}) = 0
epoll_ctl(13, EPOLL_CTL_DEL, 78, {0, {u32=149035320, u64=149035320}}) = 0
epoll_ctl(13, EPOLL_CTL_ADD, 78, {EPOLLIN|EPOLLPRI|EPOLLERR|EPOLLHUP, 
{u32=149035320, u64=149035320}}) = 0
epoll_ctl(13, EPOLL_CTL_DEL, 78, {0, {u32=149035320, u64=149035320}}) = 0
epoll_ctl(13, EPOLL_CTL_ADD, 78, {EPOLLIN|EPOLLPRI|EPOLLERR|EPOLLHUP, 
{u32=149035320, u64=149035320}}) = 0
epoll_ctl(13, EPOLL_CTL_DEL, 78, {0, {u32=149035320, u64=149035320}}) = 0
epoll_ctl(13, EPOLL_CTL_ADD, 78, {EPOLLIN|EPOLLPRI|EPOLLERR|EPOLLHUP, 
{u32=149035320, u64=149035320}}) = 0
epoll_ctl(13, EPOLL_CTL_DEL, 78, {0, {u32=149035320, u64=149035320}}) = 0
epoll_ctl(13, EPOLL_CTL_ADD, 78, {EPOLLIN|EPOLLPRI|EPOLLERR|EPOLLHUP, 
{u32=149035320, u64=149035320}}) = 0
epoll_ctl(13, EPOLL_CTL_DEL, 78, {0, {u32=149035320, u64=149035320}}) = 0
epoll_ctl(13, EPOLL_CTL_ADD, 78, {EPOLLIN|EPOLLPRI|EPOLLERR|EPOLLHUP, 
{u32=149035320, u64=149035320}}) = 0
epoll_ctl(13, EPOLL_CTL_DEL, 78, {0, {u32=149035320, u64=149035320}}) = 0
epoll_ctl(13, EPOLL_CTL_ADD, 78, {EPOLLIN|EPOLLPRI|EPOLLERR|EPOLLHUP, 
{u32=149035320, u64=149035320}}) = 0
epoll_ctl(13, EPOLL_CTL_DEL, 78, {0, {u32=149035320, u64=149035320}}) = 0
epoll_ctl(13, EPOLL_CTL_ADD, 78, {EPOLLIN|EPOLLPRI|EPOLLERR|EPOLLHUP, 
{u32=149035320, u64=149035320}}) = 0
epoll_ctl(13, EPOLL_CTL_DEL, 78, {0, {u32=149035320, u64=149035320}}) = 0
epoll_ctl(13, EPOLL_CTL_ADD, 78, {EPOLLIN|EPOLLPRI|EPOLLERR|EPOLLHUP, 
{u32=149035320, u64=149035320}}) = 0
epoll_ctl(13, EPOLL_CTL_DEL, 78, {0, {u32=149035320, u64=149035320}}) = 0
epoll_ctl(13, EPOLL_CTL_ADD, 78, {EPOLLIN|EPOLLPRI|EPOLLERR|EPOLLHUP, 
{u32=149035320, u64=149035320}}) = 0
epoll_ctl(13, EPOLL_CTL_DEL, 78, {0, {u32=149035320, u64=149035320}}) = 0
epoll_ctl(13, EPOLL_CTL_ADD, 78, {EPOLLIN|EPOLLPRI|EPOLLERR|EPOLLHUP, 
{u32=149035320, u64=149035320}}) = 0
epoll_ctl(13, EPOLL_CTL_DEL, 78, {0, {u32=149035320, u64=149035320}}) = 0
epoll_ctl(13, EPOLL_CTL_ADD, 78, {EPOLLIN|EPOLLPRI|EPOLLERR|EPOLLHUP, 
{u32=149035320, u64=149035320}}) = 0
epoll_ctl(13, EPOLL_CTL_DEL, 78, {0, {u32=149035320, u64=149035320}}) = 0
epoll_ctl(13, EPOLL_CTL_ADD, 78, {EPOLLIN|EPOLLPRI|EPOLLERR|EPOLLHUP, 
{u32=149035320, u64=149035320}}) = 0
epoll_ctl(13, EPOLL_CTL_DEL, 78, {0, {u32=149035320, u64=149035320}}) = 0
epoll_ctl(13, EPOLL_CTL_ADD, 78, {EPOLLIN|EPOLLPRI|EPOLLERR|EPOLLHUP, 
{u32=149035320, u64=149035320}}) = 0
epoll_ctl(13, EPOLL_CTL_DEL, 78, {0, {u32=149035320, u64=149035320}}) = 0
epoll_ctl(13, EPOLL_CTL_ADD, 78, {EPOLLIN|EPOLLPRI|EPOLLERR|EPOLLHUP, 
{u32=149035320, u64=149035320}}) = 0
epoll_ctl(13, EPOLL_CTL_DEL, 78, {0, {u32=149035320, u64=149035320}}) = 0
epoll_ctl(13, EPOLL_CTL_ADD, 78, {EPOLLIN|EPOLLPRI|EPOLLERR|EPOLLHUP, 
{u32=149035320, u64=149035320}}) = 0
epoll_ctl(13, EPOLL_CTL_DEL, 78, {0, {u32=149035320, u64=149035320}}) = 0
epoll_ctl(13, EPOLL_CTL_ADD, 78, {EPOLLIN|EPOLLPRI|EPOLLERR|EPOLLHUP, 
{u32=149035320, u64=149035320}}) = 0
epoll_ctl(13, EPOLL_CTL_DEL, 78, {0, {u32=149035320, u64=149035320}}) = 0
epoll_ctl(13, EPOLL_CTL_ADD, 78, {EPOLLIN|EPOLLPRI|EPOLLERR|EPOLLHUP, 
{u32=149035320, u64=149035320}}) = 0
...
...
...

FD 13 is "anon_inode:[eventpoll]"

Killing (with -9) the director process, without stopping or restarting the 
service, restores 
the correct behaviour.



*Simone Lazzaris*
*Qcom S.p.A.*
simone.lazza...@qcom.it[1] | www.qcom.it[2]
* LinkedIn[3]* | *Facebook[4]*
[5] 







[1] mailto:simone.lazza...@qcom.it
[2] https://www.qcom.it
[3] https://www.linkedin.com/company/qcom-spa
[4] http://www.facebook.com/qcomspa
[5] https://www.qcom.it/includes/email-banner.gif

Re: Auth process sometimes stop responding after upgrade

2018-09-07 Thread Aki Tuomi 
Try tracing auth-worker process instead, as sql uses worker.
---Aki TuomiDovecot oy
 Original message From: Simone Lazzaris 
 Date: 07/09/2018  12:59  (GMT+02:00) To: Sami 
Ketola  Cc: Dovecot Mailing List , 
Aki Tuomi  Subject: Re: Auth process sometimes stop 
responding after upgrade 

In data venerdì 7 settembre 2018 11:20:49 CEST, Sami Ketola ha scritto:
> > On 7 Sep 2018, at 11.25, Simone Lazzaris  wrote:
> > Actually, I have a poolmon script running that should drop vhost count for
> > unresponsive backends; the strage thing is, the backends are NOT
> > unresponsive, they are working as ususal.
> If it's this one https://github.com/brandond/poolmon/blob/master/poolmon
>  you are running
> and old version of it as the latest version is more compatible with recent
> dovecot releases.
> 
> current version in git correctly uses HOST-DOWN and HOST-FLUSH instead of
> modifying vhost count.
> 
 
Interesting, I'll surely upgrade the script in the next days. Thanks for the 
hint.
 
But the script is surely not the ultimate cause of the failures: the backend 
(and the script itself) are untouched  - and working - since many moons ago. 
 
The only modified entity is dovecot on the frontends. 
 
And even in the event of some (3 out of 8, in this very case) backends marked 
as failed, the authentication on the frontends should work, shouldn't it?
 
I've tried to strace the auth process during the last failure, and this is what 
I've got:
 
Process 2539 attached - interrupt to quit
gettimeofday({1536308480, 998803}, NULL) = 0
epoll_wait(15, 
 
After about 60 seconds, I've aborted the strace and restarted dovecot to avoid 
upsetting customers. Searching for file descriptor #15 in /proc//fd I found 
"anon_inode:[eventpoll]"

-- 
Simone Lazzaris
Responsabile datacenter

Qcom S.p.A.
Via Roggia Vignola, 9 | 24047 Treviglio (BG)
T +39036347905 | D +3903631970352| M +393938111237
simone.lazza...@qcom.it | www.qcom.it

Qcom Official Pages LinkedIn | Facebook

Re: Auth process sometimes stop responding after upgrade

2018-09-07 Thread Simone Lazzaris 
In data venerdì 7 settembre 2018 11:20:49 CEST, Sami Ketola ha scritto:
> > On 7 Sep 2018, at 11.25, Simone Lazzaris  wrote:
> > Actually, I have a poolmon script running that should drop vhost count for
> > unresponsive backends; the strage thing is, the backends are NOT
> > unresponsive, they are working as ususal.
> If it's this one https://github.com/brandond/poolmon/blob/master/poolmon
>  you are running
> and old version of it as the latest version is more compatible with recent
> dovecot releases.
> 
> current version in git correctly uses HOST-DOWN and HOST-FLUSH instead of
> modifying vhost count.
> 

Interesting, I'll surely upgrade the script in the next days. Thanks for the 
hint.

But the script is surely not the ultimate cause of the failures: the backend 
(and the script 
itself) are untouched  - and working - since many moons ago. 

The only modified entity is dovecot on the frontends. 

And even in the event of some (3 out of 8, in this very case) backends marked 
as failed, the 
authentication on the frontends should work, shouldn't it?

I've tried to strace the auth process during the last failure, and this is what 
I've got:

Process 2539 attached - interrupt to quit
gettimeofday({1536308480, 998803}, NULL) = 0
epoll_wait(15, 

After about 60 seconds, I've aborted the strace and restarted dovecot to avoid 
upsetting 
customers. Searching for file descriptor #15 in /proc//fd I found 
"anon_inode:
[eventpoll]"


*Simone Lazzaris*
*Qcom S.p.A.*
simone.lazza...@qcom.it[1] | www.qcom.it[2]
* LinkedIn[3]* | *Facebook[4]*
[5] 







[1] mailto:simone.lazza...@qcom.it
[2] https://www.qcom.it
[3] https://www.linkedin.com/company/qcom-spa
[4] http://www.facebook.com/qcomspa
[5] https://www.qcom.it/includes/email-banner.gif

Re: Auth process sometimes stop responding after upgrade

2018-09-07 Thread Simone Lazzaris 
In data venerdì 7 settembre 2018 10:06:00 CEST, Sami Ketola ha scritto:
> > On 7 Sep 2018, at 11.00, Simone Lazzaris 
> > wrote:
> > 
> > 
> > The only suspect thing is this:
> > 
> > Sep  6 14:45:41 imap-front13 dovecot: director: doveadm: Host
> > 192.168.1.142
> > vhost count changed from 100 to 0
> > Sep  6 14:45:41 imap-front13 dovecot: director: doveadm: Host
> > 192.168.1.143
> > vhost count changed from 100 to 0
> > Sep  6 14:45:41 imap-front13 dovecot: director: doveadm: Host
> > 192.168.1.219
> > vhost count changed from 100 to 0
> > 
> > Nothing on the other system logs (e.g. kernel, daemon, syslog, messages
> > ).
> Any idea what is changing the vhost count on the backends? Do you have some
> script running that possibly does change the vhost count for some
> triggering event?
> 
> Sami

Actually, I have a poolmon script running that should drop vhost count for 
unresponsive 
backends; the strage thing is, the backends are NOT unresponsive, they are 
working as 
ususal.


*Simone Lazzaris*
*Qcom S.p.A.*
simone.lazza...@qcom.it[1] | www.qcom.it[2]
* LinkedIn[3]* | *Facebook[4]*
[5] 







[1] mailto:simone.lazza...@qcom.it
[2] https://www.qcom.it
[3] https://www.linkedin.com/company/qcom-spa
[4] http://www.facebook.com/qcomspa
[5] https://www.qcom.it/includes/email-banner.gif

Re: Auth process sometimes stop responding after upgrade

2018-09-07 Thread Sami Ketola 


> On 7 Sep 2018, at 11.25, Simone Lazzaris  wrote:
> Actually, I have a poolmon script running that should drop vhost count for 
> unresponsive backends; the strage thing is, the backends are NOT 
> unresponsive, they are working as ususal.
> 

If it's this one https://github.com/brandond/poolmon/blob/master/poolmon 
 
you are running and old version of it as the latest version is more compatible 
with recent dovecot releases.

current version in git correctly uses HOST-DOWN and HOST-FLUSH instead of 
modifying vhost count.

But even then I still consider poolmon a bit too aggressive in marking hosts 
down. It does HOST-DOWN and HOST-FLUSH already after first scan failure. 
Maybe there should be some grace period and wait for few failed polls in 
certain period before doing it in case there is some temporary overload or 
networking failure.

Sami

Re: Auth process sometimes stop responding after upgrade

2018-09-07 Thread Simone Lazzaris 
In data venerdì 7 settembre 2018 10:06:00 CEST, Sami Ketola ha scritto:
> > On 7 Sep 2018, at 11.00, Simone Lazzaris 
> > wrote:
> > 
> > 
> > The only suspect thing is this:
> > 
> > Sep  6 14:45:41 imap-front13 dovecot: director: doveadm: Host
> > 192.168.1.142
> > vhost count changed from 100 to 0
> > Sep  6 14:45:41 imap-front13 dovecot: director: doveadm: Host
> > 192.168.1.143
> > vhost count changed from 100 to 0
> > Sep  6 14:45:41 imap-front13 dovecot: director: doveadm: Host
> > 192.168.1.219
> > vhost count changed from 100 to 0
> > 
> > Nothing on the other system logs (e.g. kernel, daemon, syslog, messages
> > ).
> Any idea what is changing the vhost count on the backends? Do you have some
> script running that possibly does change the vhost count for some
> triggering event?
> 
> Sami

Actually, I have a poolmon script running that should drop vhost count for 
unresponsive backends; the strage thing is, the backends are NOT unresponsive, 
they are working as ususal.


To be honest, the configuration that keep failing (again, right now) has imap-
login not configured as I've told you. The configuration you saw was an 
attempt to overcame the problem, in which I've set pop3-login like this:

service pop3-login {
  executable = imap-login director
  service_count = 0
  vsz_limit = 128 M
}

But the machines that fails are like this:

service pop3-login {
  executable = pop3-login director
}

I've got 4 VM configured in the ring. The one with service_count=0 has (so 
far) never failed, the other 3 has failed multiple time (every few hours).

-- 
*Simone Lazzaris*
*Qcom S.p.A.*

Re: Auth process sometimes stop responding after upgrade

2018-09-07 Thread Sami Ketola 



> On 7 Sep 2018, at 11.00, Simone Lazzaris  wrote:
> 
> 
> The only suspect thing is this:
> 
> Sep  6 14:45:41 imap-front13 dovecot: director: doveadm: Host 192.168.1.142 
> vhost count changed from 100 to 0
> Sep  6 14:45:41 imap-front13 dovecot: director: doveadm: Host 192.168.1.143 
> vhost count changed from 100 to 0
> Sep  6 14:45:41 imap-front13 dovecot: director: doveadm: Host 192.168.1.219 
> vhost count changed from 100 to 0
> 
> Nothing on the other system logs (e.g. kernel, daemon, syslog, messages ).

Any idea what is changing the vhost count on the backends? Do you have some 
script running that possibly does change the vhost count for some triggering 
event?

Sami

Re: Auth process sometimes stop responding after upgrade

2018-09-07 Thread Simone Lazzaris 
In data venerdì 7 settembre 2018 09:39:23 CEST, Aki Tuomi ha scritto:
> Do you see anything else in logs? 
> 

Just the usual proxy messages, like these:

Sep  6 14:45:41 imap-front13 dovecot: imap-login: 
proxy(alessan...@soldinicarrelli.it): disconnecting 5.169.233.224 
(Disconnected by server(0s idle, in=451, out=3556)): 
user=, method=PLAIN, rip=5.169.233.224, 
lip=80.76.81.92, TLS, session=

Sep  6 14:45:51 imap-front13 dovecot: pop3-login: proxy(p...@pedrini.it): 
started proxying to 192.168.1.144:110: user=, method=DIGEST-
MD5, rip=5.34.191.10, lip=80.76.81.92, TLS, session=


The only suspect thing is this:

Sep  6 14:45:41 imap-front13 dovecot: director: doveadm: Host 192.168.1.142 
vhost count changed from 100 to 0
Sep  6 14:45:41 imap-front13 dovecot: director: doveadm: Host 192.168.1.143 
vhost count changed from 100 to 0
Sep  6 14:45:41 imap-front13 dovecot: director: doveadm: Host 192.168.1.219 
vhost count changed from 100 to 0

Nothing on the other system logs (e.g. kernel, daemon, syslog, messages ).

-- 
*Simone Lazzaris*
*Qcom S.p.A.*

Re: Auth process sometimes stop responding after upgrade

2018-09-07 Thread Aki Tuomi 
Do you see anything else in logs? 


---Aki TuomiDovecot oy
 Original message From: Simone Lazzaris 
 Date: 07/09/2018  10:13  (GMT+02:00) To: 
dovecot@dovecot.org Subject: Auth process sometimes stop responding after 
upgrade 
Hi all;
I've upgraded a ring of dovecot directors from 2.2.15 to 2.2.36. After the 
upgrade I've got some instability: a few time per day per server, seemly at 
random, the auth process stop responding and the clients cannot authenticate 
any more:

Sep  6 14:45:51 imap-front13 dovecot: pop3-login: Warning: Auth process not 
responding, delayed sending initial response (greeting): user=<>, 
rip=xx.xx.xx.xx, lip=xx.xx.xx.xx, TLS, session=<1HVqRTN10MNTie+S>

I can't figure it out Any hints?

This is my configuration:


# 2.2.36 (1f10bfa63): /usr/local/etc/dovecot/dovecot.conf
# OS: Linux 3.2.0-4-686-pae i686 Debian 7.11 
# Hostname: imap-front13.mailfarm.interac.it
auth_mechanisms = plain login digest-md5 cram-md5 apop scram-sha-1
auth_verbose = yes
auth_verbose_passwords = plain
auth_worker_max_count = 50
base_dir = /var/run/dovecot/
default_login_user = nobody
director_doveadm_port = 9091
director_mail_servers = 192.168.1.142 192.168.1.143 192.168.1.144 
192.168.1.145 192.168.1.216 192.168.1.217 192.168.1.218 192.168.1.219
director_servers = 212.183.164.157 212.183.164.158 212.183.164.159 
212.183.164.160
listen = *
passdb {
  args = /usr/local/etc/dovecot/sql.conf
  driver = sql
}
protocols = imap pop3
service director {
  fifo_listener login/proxy-notify {
    mode = 0666
  }
  inet_listener {
    port = 9090
  }
  unix_listener director-userdb {
    mode = 0600
  }
  unix_listener login/director {
    mode = 0666
  }
}
service imap-login {
  executable = imap-login director
  service_count = 0
  vsz_limit = 128 M
}
service pop3-login {
  executable = pop3-login director
  service_count = 0
  vsz_limit = 128 M
}
ssl_cert =

Auth process sometimes stop responding after upgrade

2018-09-07 Thread Simone Lazzaris 
Hi all;
I've upgraded a ring of dovecot directors from 2.2.15 to 2.2.36. After the 
upgrade I've got some instability: a few time per day per server, seemly at 
random, the auth process stop responding and the clients cannot authenticate 
any more:

Sep  6 14:45:51 imap-front13 dovecot: pop3-login: Warning: Auth process not 
responding, delayed sending initial response (greeting): user=<>, 
rip=xx.xx.xx.xx, lip=xx.xx.xx.xx, TLS, session=<1HVqRTN10MNTie+S>

I can't figure it out Any hints?

This is my configuration:


# 2.2.36 (1f10bfa63): /usr/local/etc/dovecot/dovecot.conf
# OS: Linux 3.2.0-4-686-pae i686 Debian 7.11 
# Hostname: imap-front13.mailfarm.interac.it
auth_mechanisms = plain login digest-md5 cram-md5 apop scram-sha-1
auth_verbose = yes
auth_verbose_passwords = plain
auth_worker_max_count = 50
base_dir = /var/run/dovecot/
default_login_user = nobody
director_doveadm_port = 9091
director_mail_servers = 192.168.1.142 192.168.1.143 192.168.1.144 
192.168.1.145 192.168.1.216 192.168.1.217 192.168.1.218 192.168.1.219
director_servers = 212.183.164.157 212.183.164.158 212.183.164.159 
212.183.164.160
listen = *
passdb {
  args = /usr/local/etc/dovecot/sql.conf
  driver = sql
}
protocols = imap pop3
service director {
  fifo_listener login/proxy-notify {
mode = 0666
  }
  inet_listener {
port = 9090
  }
  unix_listener director-userdb {
mode = 0600
  }
  unix_listener login/director {
mode = 0666
  }
}
service imap-login {
  executable = imap-login director
  service_count = 0
  vsz_limit = 128 M
}
service pop3-login {
  executable = pop3-login director
  service_count = 0
  vsz_limit = 128 M
}
ssl_cert =