Len, My first step was to set up WUG to 20 seconds. No improvements. I know that maybe other MXs problems arise, but even by manually do postmap, takes waaaaay long, around these 20 minutes I told. And the maillog is *empty* from the minute 09:15:36 to the minute 09:34:01, so even if the port 25 is listening, sounds like a nap for this while.... On monday, at 09:16 I'll do this 'sockstat -4' and let you know.
Regards and thanks Andres ----- Mensaje original ----- De: "Len Conrad" <[EMAIL PROTECTED]> Para: <[EMAIL PROTECTED]> Enviado: s�bado, 15 de noviembre de 2003 13:10 Asunto: [IMGate] Re: Postmap hogs SMTP > > > >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 > > > > >
