[Dovecot] do not lose mail when dovecot is dead
Hi!
Recently I've experienced problems with dovecot. Dovecot died silently, what means is that there are no core files, nor any indication in the log files, just the "kevent(): Invalid argument" messages. Dovecot just died, so deliver could not connect to the auth-master socket, which means that messages couldn't been delivered. The problem is that postfix thought that the delivery was successful, and didn't place the message to delay, but deliver(LDA) couldn't deliver the message, so it got lost.
An example: postfix/pickup[29619]: 8A1C6F261: uid=1001 from=<id> postfix/cleanup[19148]: 8A1C6F261: message-id=20080107192402.8A1C6F261@domain.hu postfix/qmgr[29441]: 8A1C6F261: from=id@domain.hu, size=585, nrcpt=1 (queue active) deliver(leva): Loading modules from directory: /usr/local/lib/dovecot/lda deliver(leva): Module loaded: /usr/local/lib/dovecot/lda/lib10_quota_plugin.so deliver(leva): Module loaded: /usr/local/lib/dovecot/lda/lib90_cmusieve_plugin.so deliver(leva): Can't connect to auth server at /var/run/dovecot/auth-master: Connection refused postfix/pipe[8582]: 8A1C6F261: to=leva@domain.hu, orig_to=<id>, relay=dovecot-lda, delay=1.7, delays=1.1/0/0/0 .68, dsn=2.0.0, status=sent (delivered via dovecot-lda service) postfix/qmgr[29441]: 8A1C6F261: removed
See? Postfix removed it from the queue, so basically all bets are off, and everything depends on deliver, but it just dropped the message. Is there anything that can be done regarding this issue?
Thanks!
Daniel
On Mon, 2008-01-07 at 21:50 +0100, Daniel wrote:
Recently I've experienced problems with dovecot. Dovecot died silently, what means is that there are no core files, nor any indication in the log files, just the "kevent(): Invalid argument" messages.
Any of them begin with "Fatal: "? Why is it giving kevent() errors anyway? Those shouldn't happen.
deliver(leva): Can't connect to auth server at /var/run/dovecot/auth-master: Connection refused postfix/pipe[8582]: 8A1C6F261: to=leva@domain.hu, orig_to=<id>, relay=dovecot-lda, delay=1.7, delays=1.1/0/0/0 .68, dsn=2.0.0, status=sent (delivered via dovecot-lda service) postfix/qmgr[29441]: 8A1C6F261: removed
See? Postfix removed it from the queue, so basically all bets are off, and everything depends on deliver, but it just dropped the message. Is there anything that can be done regarding this issue?
Are you using some pre-v1.0.0 release? With v1.0.10 it seems to work correctly:
% echo foo|./deliver -d user
deliver(user): Jan 10 06:20:47 Error: Can't connect to auth server at /usr/local/var/run/dovecot/auth-master: No such file or directory
% echo $? 75 % grep 75 /usr/include/sysexits.h #define EX_TEMPFAIL 75 /* temp failure; user is invited to retry */
On Thursday 10 January 2008 05:24:01 Timo Sirainen wrote:
On Mon, 2008-01-07 at 21:50 +0100, Daniel wrote:
Recently I've experienced problems with dovecot. Dovecot died silently, what means is that there are no core files, nor any indication in the log files, just the "kevent(): Invalid argument" messages.
Any of them begin with "Fatal: "? Why is it giving kevent() errors anyway? Those shouldn't happen. Yes, this is all I get in the error log, and then dovecot dies silently. It won't produce a core file, or any indication of dying in the log file. Btw, I'm using OpenBSD 4.2, and kqueue.
deliver(leva): Can't connect to auth server at /var/run/dovecot/auth-master: Connection refused postfix/pipe[8582]: 8A1C6F261: to=leva@domain.hu, orig_to=<id>, relay=dovecot-lda, delay=1.7, delays=1.1/0/0/0 .68, dsn=2.0.0, status=sent (delivered via dovecot-lda service) postfix/qmgr[29441]: 8A1C6F261: removed
See? Postfix removed it from the queue, so basically all bets are off, and everything depends on deliver, but it just dropped the message. Is there anything that can be done regarding this issue?
Are you using some pre-v1.0.0 release? With v1.0.10 it seems to work correctly:
I'm updating dovecot with hg from HEAD.
% echo foo|./deliver -d user
deliver(user): Jan 10 06:20:47 Error: Can't connect to auth server at /usr/local/var/run/dovecot/auth-master: No such file or directory
Maybe my auth-master file remains there, but deliver couldn't connect to it, because dovecot has died. I guess the socket stayed there because dovecot couldn't clean up after itself in this case. Am I wrong (just guessing leastways...)?
% echo $? 75 % grep 75 /usr/include/sysexits.h #define EX_TEMPFAIL 75 /* temp failure; user is invited to retry */
On Thu, 2008-01-10 at 18:53 +0100, Daniel wrote:
deliver(leva): Can't connect to auth server at /var/run/dovecot/auth-master: Connection refused postfix/pipe[8582]: 8A1C6F261: to=leva@domain.hu, orig_to=<id>, relay=dovecot-lda, delay=1.7, delays=1.1/0/0/0 .68, dsn=2.0.0, status=sent (delivered via dovecot-lda service) postfix/qmgr[29441]: 8A1C6F261: removed
I don't know why this would happen though. How are you executing deliver? I think the problem is with Postfix configuration or at least outside deliver.
Maybe my auth-master file remains there, but deliver couldn't connect to it, because dovecot has died. I guess the socket stayed there because dovecot couldn't clean up after itself in this case. Am I wrong (just guessing leastways...)?
I tested that in that situation deliver also returns temporary failure.
On Saturday 12 January 2008 09:54:03 Timo Sirainen wrote:
On Thu, 2008-01-10 at 18:53 +0100, Daniel wrote:
deliver(leva): Can't connect to auth server at /var/run/dovecot/auth-master: Connection refused postfix/pipe[8582]: 8A1C6F261: to=leva@domain.hu, orig_to=<id>, relay=dovecot-lda, delay=1.7, delays=1.1/0/0/0 .68, dsn=2.0.0, status=sent (delivered via dovecot-lda service) postfix/qmgr[29441]: 8A1C6F261: removed
I don't know why this would happen though. How are you executing deliver? I think the problem is with Postfix configuration or at least outside deliver. Currently, I'm executing deliver from a wrapper script: # master.cf: dovecot-lda unix [...] argv=[...]/dovecot-lda_wrapper.pl ${recipient}
That script finds out the username which must be passed to deliver's -d option, because dovecot's user names are not the same as the recipient email addresses of the user's, so I can not just execute deliver directly with the -d ${recipient} option. This hack prevented deliver's exit code to get recognized by postfix.
Maybe my auth-master file remains there, but deliver couldn't connect to it, because dovecot has died. I guess the socket stayed there because dovecot couldn't clean up after itself in this case. Am I wrong (just guessing leastways...)?
I tested that in that situation deliver also returns temporary failure.
Daniel
On Sat, 12 Jan 2008, Daniel wrote:
Currently, I'm executing deliver from a wrapper script: # master.cf: dovecot-lda unix [...] argv=[...]/dovecot-lda_wrapper.pl ${recipient}
That script finds out the username which must be passed to deliver's -d option, because dovecot's user names are not the same as the recipient email addresses of the user's, so I can not just execute deliver directly with the -d ${recipient} option. This hack prevented deliver's exit code to get recognized by postfix.
Can you fix your dovecot-lda_wrapper.pl to either "exec" deliver, so that when it exits your process exits with the same number, or to do the Perl equivalent of "exit $?" - that is, exit the wrapper process with the exit code of the Dovecot LDA?
-- Asheesh.
-- Imitation is the sincerest form of television. -- Fred Allen
On Saturday 12 January 2008 21:50:48 Asheesh Laroia wrote:
On Sat, 12 Jan 2008, Daniel wrote:
Currently, I'm executing deliver from a wrapper script: # master.cf: dovecot-lda unix [...] argv=[...]/dovecot-lda_wrapper.pl ${recipient}
That script finds out the username which must be passed to deliver's -d option, because dovecot's user names are not the same as the recipient email addresses of the user's, so I can not just execute deliver directly with the -d ${recipient} option. This hack prevented deliver's exit code to get recognized by postfix.
Can you fix your dovecot-lda_wrapper.pl to either "exec" deliver, so that when it exits your process exits with the same number, or to do the Perl equivalent of "exit $?" - that is, exit the wrapper process with the exit code of the Dovecot LDA? Yes, I've been experimenting with the latter for a few hours now, and it is currently being tested.
Thanks!
Daniel
On 20:25:52 2008-01-12 Daniel leva@az.isten.hu wrote:
On Saturday 12 January 2008 09:54:03 Timo Sirainen wrote:
On Thu, 2008-01-10 at 18:53 +0100, Daniel wrote:
deliver(leva): Can't connect to auth server at /var/run/dovecot/auth-master: Connection refused postfix/pipe[8582]: 8A1C6F261: to=leva@domain.hu, orig_to=<id>, relay=dovecot-lda, delay=1.7, delays=1.1/0/0/0 .68, dsn=2.0.0, status=sent (delivered via dovecot-lda service) postfix/qmgr[29441]: 8A1C6F261: removed
I don't know why this would happen though. How are you executing deliver? I think the problem is with Postfix configuration or at least outside deliver. Currently, I'm executing deliver from a wrapper script: # master.cf: dovecot-lda unix [...] argv=[...]/dovecot-lda_wrapper.pl ${recipient}
That script finds out the username which must be passed to deliver's -d option, because dovecot's user names are not the same as the recipient email addresses of the user's, so I can not just execute deliver directly with the -d ${recipient} option. This hack prevented deliver's exit code to get recognized by postfix.
I'm confused... why does email addy differ from username??? Can you explain? Why not just have username@domain and anything else as an alias???
-- Andraž "ruskie" Levstik Source Mage GNU/Linux Games grimoire guru Geek/Hacker/Tinker
Be sure brain is in gear before engaging mouth.
Key id = F4C1F89C Key fingerprint = 6FF2 8F20 4C9D DB36 B5B6 F134 884D 72CC F4C1 F89C
On 1/12/2008, Daniel (leva@az.isten.hu) wrote:
That script finds out the username which must be passed to deliver's -d option, because dovecot's user names are not the same as the recipient email addresses of the user's,
Curious - why is that? I'm just trying to think of a situation where the username and recipient would be different...
--
Best regards,
Charles
On Saturday 12 January 2008 23:36:00 Charles Marcus wrote:
On 1/12/2008, Daniel (leva@az.isten.hu) wrote:
That script finds out the username which must be passed to deliver's -d option, because dovecot's user names are not the same as the recipient email addresses of the user's,
Curious - why is that? I'm just trying to think of a situation where the username and recipient would be different...
Eg. when a customer says: "Hey, I want my username to be "foo", and my email to be "bar@domain.com". :)
Daniel
Eg. when a customer says: "Hey, I want my username to be "foo", and my email to be "bar@domain.com". :)
I encourage that on my servers. It's just one more layer of defense
against password guessing zombies; beats me if it makes any difference.
I don't want to give them the userid for free just because they saw the
email address on some spam list.
participants (6)
-
"Andraž 'ruskie' Levstik"
-
Asheesh Laroia
-
Charles Marcus
-
Daniel
-
Timo Sirainen
-
WJCarpenter