You got me!!! I have only been running corporate e-mail on Postfix for a couple of decades and still learning the basics.
It does not require a lot of expertise until something goes wrong!

I knew that you or Wietse or one of the other experts would correct my guesses.

You guys give great support on a product that is very complex but does damn near everything possible with mail.

Ron

On 2020-10-26 2:59 p.m., Viktor Dukhovni wrote:
On Mon, Oct 26, 2020 at 10:07:25AM +0000, Pedro David Marco wrote:

Flushing the queue with 'postqueue -f' normally produces instant
flush but sometimes it takes some time to do it... it always works!
It never produces "instant flush", what it does is reset the queue
manager's delay timer for the next deferred queue scan, so that if no
deferred queue scan is currently in progress, it starts now, or if
already in progress, the next scan will start as soon as the current one
completes.

Furthermore, instead of retrying just the messages whose retry time is
in the past, for the next scan (and any remaining portion of the current
scan) all messages will be retried.

but sometimes with a long delay...  just out of curiosity... why does
this happen? is it qmgr daemon waiting for anything? is there any way
for force it?
As Wietse noted, without more information about what's in the queue at
the time, etc. it is hard to say.  One would expective to see "qmgr" log
messages showing mail entering the active queue, e.g.:

     Oct 26 14:43:56 amnesiac postfix/qmgr[97795]: E0BFA3BC92C:
         from=<rfc-interest-boun...@rfc-editor.org>,
         size=11617, nrcpt=1 (queue active)

but perhaps your logging subsystem is losing messages.

On Mon, Oct 26, 2020 at 04:22:21PM +0000, Pedro David Marco wrote:

On Monday, October 26, 2020, 05:09:41 PM GMT+1, Ron Wheeler 
<rwhee...@artifact-software.com> wrote:
You might want to take a look at what is in the queue.
Flushing the queue means communicating with other mail servers and
the reason that mail is in the queue is that it was "too hard" to
deliver it the first time.  A broken or overloaded remote could still
be slow.
Ron is not well informed on this topic, and is just guessing.

Just a real example: 100 emails in deferred queue due to connection
timed out (remote host was down for a while). Once the remote is up
again, i run postqueue -f  for quickdelivery...Sometimes it works
immediatelly, and sometimes there is a delay... (with no postfix log
activity at all)
Your logging subsystem may be losing messages, are you seeing logging
from the queue manager at all?  With "postqueue -f", and deferred
messages in the queue, you should be seeing "qmgr" log messages about
new mail entering the queue, which would show up promptly, unless
you're using a particularly sluggish transport table (slow LDAP,
overloaded MySQL, ...).

On Mon, Oct 26, 2020 at 04:44:11PM +0000, Pedro David Marco wrote:

  >On Monday, October 26, 2020, 05:31:05 PM GMT+1, Ron Wheeler 
<rwhee...@artifact-software.com> wrote:  >
Could be just that the other end was busy receiving someone else's mail. Takes 
2 to tango!
No big attachments?
Thanks Ron...  size no bigger than 500KB... if remote is busy...  in
the log at least i should see the postfix attempt, am i right? but
there is nothing at all in the log...
Message content size does not matter in this context.  Queue manager
latency depends on the number of recipients in a message (up to a limit
on the number brought into memory at once) not the message size.  With a
sufficiency low-latency transport table (none or indexed files) the
queue manager activates messages "in real time".


--
Ron Wheeler
Artifact Software
438-345-3369
rwhee...@artifact-software.com

Reply via email to