PATCH: defer when pipe command dies
in [Postfix]
|
Prev: Throttling, trivial-rewrite and problem talking toservice errors when using LDAP
Next: reverse hostname (ok) -> fw dns query (ko) -> unknow
From: Jeroen Geilman on 14 Jul 2010 18:23 On 07/14/2010 10:29 PM, Victor Duchovni wrote: > On Wed, Jul 14, 2010 at 07:56:36PM +0200, Jeroen Geilman wrote: > > >>> postfix/pipe[15018]: A481A3B: to=<user(a)example.com>, relay=dovecot, >>> delay=0.32, delays=0.26/0.02/0/0.04, dsn=4.3.0, status=deferred (Command >>> died with signal 7: "/usr/libexec/dovecot/deliver") >>> postfix/pipe[15173]: A481A3B: to=<user(a)example.com>, relay=dovecot, >>> delay=60, delays=59/0.06/0/0.2, dsn=2.0.0, status=sent (delivered via >>> dovecot service) >>> >>> -- TA >>> >> Add "-o soft_bounce=yes" to your pipe transport. >> > That can mask real permanent non-delivery issues. Of course delivery > programs should not die with "bus errors" (or whatever signal 7 is > on the OPs system), but if they do, perhaps Postfix should retry... > > Wouldn't it still fall off the queue after maximal_queue_lifetime ? Of course, a lot depends on where it goes after that... Perhaps it's possible to set maximal_queue_lifetime for just that transport, and the OP can lower it to one day or so. J.
From: Jeroen Geilman on 14 Jul 2010 18:27 On 07/14/2010 10:29 PM, Victor Duchovni wrote: > On Wed, Jul 14, 2010 at 07:56:36PM +0200, Jeroen Geilman wrote: > > >>> postfix/pipe[15018]: A481A3B: to=<user(a)example.com>, relay=dovecot, >>> delay=0.32, delays=0.26/0.02/0/0.04, dsn=4.3.0, status=deferred (Command >>> died with signal 7: "/usr/libexec/dovecot/deliver") >>> postfix/pipe[15173]: A481A3B: to=<user(a)example.com>, relay=dovecot, >>> delay=60, delays=59/0.06/0/0.2, dsn=2.0.0, status=sent (delivered via >>> dovecot service) >>> >>> -- TA >>> >> Add "-o soft_bounce=yes" to your pipe transport. >> > That can mask real permanent non-delivery issues. I must have been sleepy... so does his "solution"!. In both cases, watching the log is required to know this is happening at all... I completely agree that non-delivery to a (presumably dependable) MDA should never error out, but I thought a soft solution would be better than choosing the more extreme route (of altering working code). J.
From: Thomas Arnett on 15 Jul 2010 18:10 Jeroen Geilman <jeroen <at> adaptr.nl> writes: > I completely agree that non-delivery to a (presumably dependable) MDA > should never error out, but I thought a soft solution would be better > than choosing the more extreme route (of altering working code). I believe the code is not working as intended and documented. Please let me know if I have missed something. -- TA
From: Victor Duchovni on 15 Jul 2010 18:27 On Thu, Jul 15, 2010 at 10:10:32PM +0000, Thomas Arnett wrote: > Jeroen Geilman <jeroen <at> adaptr.nl> writes: > > I completely agree that non-delivery to a (presumably dependable) MDA > > should never error out, but I thought a soft solution would be better > > than choosing the more extreme route (of altering working code). > > I believe the code is not working as intended and documented. Please let me know > if I have missed something. I don't think you have missed anything. The folks suggesting soft_bounce as a "solution" are not looking at the big picture. Wietse, if I understand correctly, wants to ensure that the issue is clearly defined, so we don't solve the wrong one, and is worth fixing. Not all minor bugs are worth fixing, the benefit may not outweigh the risk of unforseen consequences or implementation errors in the fix. Why does your Dovecot intermittently SIGBUS? Surely that's the real problem that needs fixing. (Yes, I would probably still change Postfix to treat killed processes as a transient condition, but I am a bit less conservative than Wietse). -- Viktor.
From: Wietse Venema on 15 Jul 2010 19:21
Victor Duchovni: > On Thu, Jul 15, 2010 at 10:10:32PM +0000, Thomas Arnett wrote: > > > Jeroen Geilman <jeroen <at> adaptr.nl> writes: > > > I completely agree that non-delivery to a (presumably dependable) MDA > > > should never error out, but I thought a soft solution would be better > > > than choosing the more extreme route (of altering working code). > > > > I believe the code is not working as intended and documented. Please let me know > > if I have missed something. > > I don't think you have missed anything. The folks suggesting soft_bounce > as a "solution" are not looking at the big picture. > > Wietse, if I understand correctly, wants to ensure that the issue is > clearly defined, so we don't solve the wrong one, and is worth fixing. > > Not all minor bugs are worth fixing, the benefit may not outweigh the > risk of unforseen consequences or implementation errors in the fix. > > Why does your Dovecot intermittently SIGBUS? Surely that's the real > problem that needs fixing. (Yes, I would probably still change Postfix > to treat killed processes as a transient condition, but I am a bit less > conservative than Wietse). I already updated Postfix a few days ago, but I don't have time to roll out a new release yet. Wietse |