Postfix smtpd processes not aware of config changes...

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Postfix smtpd processes not aware of config changes...

PeterDaem
Hi!

i have this in my main.cf:

address_verify_transport_maps = hash:/etc/postfix/transport_para_vrfy

It works ok when i add a new domain, but when i modify an exsiting one and do the corresponding postmap and postfix restart, randomly
some Postfix smtpd processes (not all of them!!!) keeps trying the old data instead of actual one!!! (as stated, this only happens with
modificacions; no problem with new entries)

To my knowledge, a postmap on transport_para_vrfy and Postfix restart is enough... but...  
It looks like not all postfix processes are aware of the config changes.

Any idea, please?

Thanks!

Pedreter.

Reply | Threaded
Open this post in threaded view
|

Re: Postfix smtpd processes not aware of config changes...

Wietse Venema
Pedro David Marco:
> Hi!
> i have this in my main.cf:
> address_verify_transport_maps = hash:/etc/postfix/transport_para_vrfy
> It works ok when i add a new domain, but when i modify an exsiting one and do the corresponding postmap and postfix restart, randomlysome Postfix smtpd processes (not all of them!!!) keeps trying the old data instead of actual one!!! (as stated, this only happens withmodificacions; no problem with new entries)
> To my knowledge, a postmap on transport_para_vrfy and Postfix restart is enough... but...??It looks like not all postfix processes are aware of the config changes.

There is no "postfix restart" in Postfix as released by me.

What does YOUR "postfix restart" do?

a) Issue "postfix stop', which terminates all deliveries that are in progress?

b) Issue "postfix reload" which does not stop deliveries that are in progress?

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Postfix smtpd processes not aware of config changes...

PeterDaem
Ops, forgot to mention that, thanks Wietse...

postfix restart means  'postfix stop ; postfix start'

maybe it would be a good idea to introduce some delay between stop and start?

Thanks,

Pedreter.


On Monday, February 22, 2021, 04:54:38 PM GMT+1, Wietse Venema <[hidden email]> wrote:


Pedro David Marco:

> Hi!
> i have this in my main.cf:
> address_verify_transport_maps = hash:/etc/postfix/transport_para_vrfy
> It works ok when i add a new domain, but when i modify an exsiting one and do the corresponding postmap and postfix restart, randomlysome Postfix smtpd processes (not all of them!!!) keeps trying the old data instead of actual one!!! (as stated, this only happens withmodificacions; no problem with new entries)
> To my knowledge, a postmap on transport_para_vrfy and Postfix restart is enough... but...??It looks like not all postfix processes are aware of the config changes.


There is no "postfix restart" in Postfix as released by me.

What does YOUR "postfix restart" do?

a) Issue "postfix stop', which terminates all deliveries that are in progress?

b) Issue "postfix reload" which does not stop deliveries that are in progress?

    Wietse

Reply | Threaded
Open this post in threaded view
|

Re: Postfix smtpd processes not aware of config changes...

Wietse Venema
Pedro David Marco:
>  Ops, forgot to mention that, thanks Wietse...
> postfix restart means? 'postfix stop ; postfix start'
> maybe it would be a good idea to introduce some delay between stop and start?

With "postfix stop", ALL Postfix processes are terminated, so they
cannot remember old database state.

Postfix does not make copies of your database unless you configured
Postfix to do that with memcache or some other cache.

If new Postfix processes see old database state, then you have a
problem with your database update procedure.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Postfix smtpd processes not aware of config changes...

Viktor Dukhovni
In reply to this post by PeterDaem
> On Feb 22, 2021, at 2:07 PM, Pedro David Marco <[hidden email]> wrote:
>
> postfix restart means  'postfix stop ; postfix start'
>
> maybe it would be a good idea to introduce some delay between stop and start?

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.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: Postfix smtpd processes not aware of config changes...

PeterDaem
Thanks Viktor and Wietse...  i will keep digging it out!!

My understading was what you said, so probably the problem is anywhere else...

thanks again!

Pedreter.

On Monday, February 22, 2021, 05:23:04 PM GMT+1, Viktor Dukhovni <[hidden email]> wrote:


> On Feb 22, 2021, at 2:07 PM, Pedro David Marco <[hidden email]> wrote:

>
> postfix restart means  'postfix stop ; postfix start'
>
> maybe it would be a good idea to introduce some delay between stop and start?


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.

--
    Viktor.