Viktor Dukhovni wrote:
> Actually, to expedite the visibility configuration changes, it is generally
> sufficient to do a "graceful" reconfiguration via "postfix reload". Or
> just do nothing, and let the change take place incrementally as processes
> "age out" (subject to $max_use and $max_idle) and are replaced.
>
> Are the changes you're making so urgent that a restart or reload is warranted?
> A restart disrupts existing inbound and outgoing connections (some mail may be
> delivered twice), while a reload disrupts the queue manager, causing all
> active
> mail to go back to incoming, and the active queue is then rebuilt.
>
> If it is not an emergency, and it was working fine before the change,
> generally
> best to let the change take place incrementally. You can reduce the latency
> by reducing $max_idle to ~5s and perhaps take $max_use down to ~20 from 100.
This touches upon something that I have never understood very well.
And I think it explains behavior I have seen that has confused me and
led me to think that something different was happening. And it all
centers around on when one must reload, or restart, or do nothing.
If I change the main.cf file then I think it is an _of_course_ that I
must then "postfix reload" for the change to take effect. All good.
If I change the /etc/aliases file then I need to run newaliases to
build the /etc/aliases.db file from the updated source. And generally
nothing more is needed. All good.
But here is the case where confusion happens. A mail server of mine
has eleven db files of the standard "default_database_type = hash"
type of files on disk. (I use a Makefile to handle updates.)
Let's say I change one of those tables, run postmap, and then the most
natural thing in the world is to *immediately* test the result of the
change. It seems to appear as if updating the db files are not
sufficient to cause this to happen immediately. And therefore I
think, should I be reloading afterward? Should I be restarting? Of
course if I restart then the change is pushed through. And I have
never quite understood reload in this context. Is reload enough?
Since reload seems to be needed, because it doesn't always work
immediately otherwise. It's this behavior that has trained people
like me and probably others that more is needed.
And then I read the above and I see the comments. Here my values are
defaulting to these.
$ postconf max_idle max_use
max_idle = 100s
max_use = 100
And now that I have become aware of those I am going to copy the
Postfix documentation here so as to try to bundle everything in one
place.
max_idle (default: 100s)
The maximum amount of time that an idle Postfix daemon process
waits for an incoming connection before terminating
voluntarily. This parameter is ignored by the Postfix queue
manager and by other long-lived Postfix daemon processes.
Time units: s (seconds), m (minutes), h (hours), d (days), w
(weeks). The default time unit is s (seconds).
max_use (default: 100)
The maximal number of incoming connections that a Postfix
daemon process will service before terminating
voluntarily. This parameter is ignored by the Postfix queue
manager and by other long-lived Postfix daemon processes.
Everything works so well generally that I have been blissfully unaware
of how this part of the machinery works. But now I see that after
updating tables the running deamons will still be attached to the
previous data of that file for 100 seconds. Perhaps expiring sooner
if they hit 100 uses first. And therefore should I be learning that
after updating tables I should wait $max_idle seconds, 100 seconds by
default (let's say 2 minutes), before testing? Is that correct?
Is there a difference if the tables are backed by a MySQL or Postgres
database?
Do I need to be aware of which tables are used by which daemon in this
decision making flow?
Just knowing that table updates require a $max_idle maximum TTL before
ensuring their effect (if that is correct) before testing the change
would be good learning. I could probably avoid reloads entirely for
table updates moving forward in this case. And then only reload for
main.cf and master.cf file updates.
Thanks!
Bob
