New E-mail/Address creation causes disruption to Postfix

[edeis]

When adding a new user or e-mail account, ispCP seams to restart postfix with an updated hash table. Unfortantely, If it does the restart during handling of an e-mail and the e-mail is dropped.

Important parts in bold and underline below:
Aug 11 10:44:58 drizzle postfix/smtpd[15981]: connect from 201-33-235-198.wln.net.br[201.33.235.198]
Aug 11 10:44:58 drizzle postfix/trivial-rewrite[15919]: table hash:/etc/postfix/ispcp/transport(0,lock|no_regsub|fold_fix) has changed -- restarting
Aug 11 10:44:58 drizzle postfix/smtpd[15981]: warning: premature end-of-input on private/rewrite socket while reading input attribute name
Aug 11 10:44:58 drizzle postfix/smtpd[15981]: warning: problem talking to service rewrite: Connection reset by peer
Aug 11 10:44:58 drizzle postfix/postfix-script: stopping the Postfix mail system
Aug 11 10:44:58 drizzle postfix/master[15910]: terminating on signal 15
Aug 11 10:44:58 drizzle dovecot: dovecot: Killed with signal 15 (by pid=16092 uid=0 code=kill)
Aug 11 10:44:59 drizzle postfix/postfix-script: starting the Postfix mail system
Aug 11 10:44:59 drizzle postfix/master[16157]: daemon started -- version 2.3.3, configuration /etc/postfix
Aug 11 10:44:59 drizzle dovecot: Dovecot v1.2.11 starting up (core dumps disabled)
Aug 11 10:44:59 drizzle dovecot: auth-worker(default): mysql: Connected to localhost (ispcp)
Aug 11 10:44:59 drizzle last message repeated 2 times

[joximu]

normally - if a mail is not sent successfully (always a good answer (like "200 OK") after every sent part), then it should be send again....
If it's not spam then the same mail should come again...

/J

[edeis]

Okay, then I can safely ignore the following error? I have a script monitoring the logs and reports whenever their is an entry for warning/error/fatal, etc.

Aug 11 10:44:58 drizzle postfix/smtpd[15981]: warning: premature end-of-input on private/rewrite socket while reading input attribute name
Aug 11 10:44:58 drizzle postfix/smtpd[15981]: warning: problem talking to service rewrite: Connection reset by peer

[joximu]

I'd say yes - ignore if it's the rewrite-reset...


/J

[Nuxwin]

(08-12-2010 07:22 AM)joximu Wrote:  normally - if a mail is not sent successfully (always a good answer (like "200 OK") after every sent part), then it should be send again....
If it's not spam then the same mail should come again...

/J

Joxi, I've not tested but maybe we should simply do a reload postfix (SIGHUP) when a new mail account is added and not do a restart (stop - start so SIGTERM) ? have you the time to test the behavior ?

Code:

Signals:

       SIGHUP Upon  receipt of a HUP signal (e.g., after "postfix
              reload"), the master process re-reads its  configu-
              ration  files.  If  a service has been removed from
              the master.cf file, its running processes are  ter-
              minated  immediately.  [b]Otherwise, running processes
              are allowed to terminate as soon as is  convenient,
              so  that  changes  in configuration settings affect
              only new service requests.[/b]

       SIGTERM
              Upon receipt of a TERM signal (e.g., after "postfix
              abort"), the master process passes the signal on to
              its child processes and terminates.  This is useful
              for  an emergency shutdown. Normally one would ter-
              minate only the master ("postfix stop")  and  allow
              running processes to finish what they are doing.

http://www.postfix.org/master.8.html

[kilburn]

Quote:normally - if a mail is not sent successfully (always a good answer (like "200 OK") after every sent part), then it should be send again....
If it's not spam then the same mail should come again...

That's right. Further, if the mail has already been accepted, postfix makes sure to not lose it afterwards. Hence, the rewrite error can be safely ignored (postfix will resume mail processing after restart).

Quote:Joxi, I've not tested but maybe we should simply do a reload postfix (SIGHUP) when a new mail account is added and not do a restart (stop - start so SIGTERM) ? have you the time to test the behavior ?

What's more, we don't even need to send a sighup when managing mail accounts. On the one hand, since we are only changing the postfix lookup tables but not any configuration values, there's no need to reload the configurations. On the other hand, postfix automatically detects changes in lookup tables and restarts the corresponding processes automatically. Hence, there's no need to reload nor restart nor anything!

Source (from postfix lookup tables docs):

Quote:If you change a local file based database such as DBM or Berkeley DB, there is no need to execute "postfix reload". Postfix uses file locking to avoid read/write access conflicts, and whenever a Postfix daemon process notices that a file has changed it will terminate before handling the next client request, so that a new process can initialize with the new database.

Cheers!

[Nuxwin]

(08-12-2010 06:57 PM)kilburn Wrote:  

Quote:normally - if a mail is not sent successfully (always a good answer (like "200 OK") after every sent part), then it should be send again....
If it's not spam then the same mail should come again...

That's right. Further, if the mail has already been accepted, postfix makes sure to not lose it afterwards. Hence, the rewrite error can be safely ignored (postfix will resume mail processing after restart).

Quote:Joxi, I've not tested but maybe we should simply do a reload postfix (SIGHUP) when a new mail account is added and not do a restart (stop - start so SIGTERM) ? have you the time to test the behavior ?

What's more, we don't even need to send a sighup when managing mail accounts. On the one hand, since we are only changing the postfix lookup tables but not any configuration values, there's no need to reload the configurations. On the other hand, postfix automatically detects changes in lookup tables and restarts the corresponding processes automatically. Hence, there's no need to reload nor restart nor anything!

Source (from postfix lookup tables docs):

Quote:If you change a local file based database such as DBM or Berkeley DB, there is no need to execute "postfix reload". Postfix uses file locking to avoid read/write access conflicts, and whenever a Postfix daemon process notices that a file has changed it will terminate before handling the next client request, so that a new process can initialize with the new database.

Cheers!

Ok Marc. Thanks. Are you nervous today ? I'll make some tests and remove the stop - start calls in the ispcp-serv-mngr engine script. Note, After thinking, I know that you have right. When we use postfixadmin, it's the same behavior. Don't need to reload postfix.

[kilburn]

Quote:Ok Marc. Thanks. Wink Are you nervous today ? I'll make some tests and remove the stop - start calls in the ispcp-serv-mngr engine script.

Nervous? Why should I be? I just don't feel like working today... :S

PS: I've tested that, when updating sasldb, there's no need to reload postfix either. It works

[Nuxwin]

(08-12-2010 07:36 PM)kilburn Wrote:  

Quote:Ok Marc. Thanks. Wink Are you nervous today ? I'll make some tests and remove the stop - start calls in the ispcp-serv-mngr engine script.

Nervous? Why should I be? I just don't feel like working today... :S

PS: I've tested that, when updating sasldb, there's no need to reload postfix either. It works

Ok, great. I say that because you have used some (!) to terminate your phrases.

http://isp-control.net/ispcp/changeset/3196

I think we should take care about others service like imap, amavis... too.

[kilburn]

Just one thing I'm not sure about: do the setup/update scripts use ispcp-srv-mngr to restart the services, or they do it their own way? I'm saying that because if there are postfix config changes during an update, it is actually imperative to reload/restart it...