>The whole process takes about 20 minutes ( from the ftp to the postmap ), >but my monitoring system, What's Up, alert me each time the postmap starts, >that the SMTP is not responding: > ># grep 09:15: /var/log/maillog >----snip------- >Nov 15 09:15:36 deimos postfix/smtpd[68639]: disconnect from >q5.elistas.net[216.66.19.153] >Nov 15 09:15:36 deimos postfix/smtpd[68616]: lookup table has changed -- >exiting >Nov 15 09:15:36 deimos postfix/smtpd[68357]: lookup table has changed -- >exiting >Nov 15 09:15:36 deimos postfix/smtpd[68613]: lookup table has changed -- >exiting >Nov 15 09:15:36 deimos postfix/smtpd[68638]: lookup table has changed -- >exiting
those log line have nothing to do with postfix not listening. Each SMTPD process will terminate itself when it detects a .map.db change. master.cf will start them up again. >----snip------- ># grep 09:33: /var/log/maillog ># grep 09:34: /var/log/maillog >Nov 15 09:34:01 deimos postfix/nqmgr[83093]: 65A6775E1B: >to=<[EMAIL PROTECTED]>, relay=none, delay=56824, status=deferred (connect >to 127.0.1.50[127.0.1.50]: Can't assign requested address) 56834 is 16 hours and has nothing to do the postmap. # dig alians.com mx ; <<>> DiG 9.2.3rc3 <<>> alians.com mx ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35986 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 0 ;; QUESTION SECTION: ;alians.com. IN MX ;; ANSWER SECTION: alians.com. 86400 IN MX 0 127.0.1.50. their MX is screwed up. The rdata field is numeric, not a fqdn, and while postfix will try to handle (and log a warning for) a numeric MX, 127/8 is the loopback network, so NOBODY can deliver to alians' MX. drop this MX's problem from your analysis of the handling of the slet file. >Nov 15 09:34:01 deimos postfix/nqmgr[83093]: 6D81875E97: from=<>, size=3136, >nrcpt=1 (queue active) > >I can see it's not respondig. WUG it's right !! your WUG threshold is way too short for the checking IMGate's port 25. make it 10 or 20 seconds to avoid false positives. >Any way to 'reduce' the 'postmap' impact ?? when you postmap from_senders_slet.map manually, how long does it take? When an smtpd process starts up, it has to open all the .map files, do various consistency checks, and it can takes a few seconds. but it doesn't take minutes. so for a few seconds, postfix will be deaf, but not for minutes. but as soon as one smtpd process is reloaded, port 25 is alive. during what you call the impact time (start it by do a postmap of the slet file), do this: sockstat -4 to see if there any an smptd listening on *:25. and fix your WUG config. Len
