[Postfixbuch-users] mails bleiben in queue haengen :-(

Wolfram Greinert greinert at rz.uni-leipzig.de
Mo Aug 5 14:21:07 CEST 2002


Hallo Herr Hildebrandt,

Ralf Hildebrandt writes:
> Am 05.08.2002 um 10:53:38 +0200 schrieb Wolfram Greinert folgendes:
> > 
> > Hallo,
> > 
> > ich wollte einen email-Virenscanner so aufbauen, dass er als relay am
> > Eingang unserer Einrichtung steht. Das Ding habe ich auf folgendem
> > System aufgesetzt:
> > 
> > AMD Athlon(tm) XP 2000+, 1 GB RAM, 2 schnelle IDE Platten
> > Linux 2.4.18 (nicht SuSE !)
> 
> Ah, weise Qahl :)

:-)

>  
> > postfix 1.1.11 + pcre-3.7 + db-4.0.14 + amavisd-snapshot-20020300
> > (Virenscanner: sweep von sophos)
> 
> Hmm, amavisd-snapshot-20020531 ist aktuell.

stimmt :-( Ich hatte das Zeug gleich von der Startseite geholt. Dort stehen
ja auch amavisd-ng rum. Sind die besser ???? Koennten die Klemmer an der
amavis-Version liegen ????

> 
> > Ausser postfix + amavisd laeuft auf der Kiste nichts (kein X usw.).
> 
> Fein!
> 
> > Im Nameserver stehen Eintraege der Form:
> > 
> > rechnera  IN MX 1  v1   (v1 ist besagte Muehle)
> > 
> > auf v1 ist "best_mx_transport = smtp" in main.cf konfiguriert und
> > ausserdem gibt es in transport den Eintrag:
> > 
> > rechnera	smtp:[ip-adresse von rechnera]
> > 
> > Zusaetzlich habe ich als Relay-Host im rechnera den v1 angegeben, damit
> > ausgehende mails auch gescannt werden.
> > 
> > Diese Konstruktion lief ca. 3 Tage perfekt, taeglich wurden mehrere
> 
> Also scheint es grundlegend korrekt zu sein.

diese Hoffnung hatte ich auch, aber nur ein paar Tage :-(

> 
> > 10000 mails durch v1 gescannt und eine Menge Viren gefunden. Die 
> > Systemauslastung lag im Prinzip bei Null (wenn ich nicht noch seti
> > gestartet haette :-), swap wurde kaum benutzt. Doch ploetzlich wollte
> > postfix keine mails mehr ausliefern. Es wurden jede Menge mails 
> > angenommen und gescannt, doch dann lagen sie nur in der queue rum und
> > smtp lieferte sie einfach nicht mehr aus (Rechnera war natuerlich auf
> > Port 25 erreichbar). Teilweise lagen ueber 3000 mails in der queue,
> > davon 200 in active (ueber qmgr_message_active_limit so eingestellt),
> > der Rest in incoming. Man konnte auch mit netstat keine aktiven 
> > Verbindungen zu rechnera:25 sehen. Kommandos wie "postfix flush" ,
> > "postqueue -f", "postsuper -s ..." zeigten keine Wirkung, der Austausch
> > von qmgr <-> nqmgr brachte auch nichts. Auch die Aenderung verschiedener
> > Parameter in main.cf (maximal_backoff_time, queue_run_delay,
> > minimal_backoff_time usw.) brachte nichts. Nur nach stop und start von
> > postfix wurden 3-20 Mails ausgeliefert, dann war wieder Ruhe :-(
> 
> Interessant. Und nix im Log? Kein Hinweis, warum nix mehr passiert?
> 
> Evtl. mal "-v" in master.cf bei (n)qmgr und smtpd dazumachen.

habe ich mal eine Weile gemacht (bei allen Modulen). Ist der echte Wahnsinn,
was da alles ausgeschrieben wird. Nur (fuer einen normalen Menschen) Hinweise
auf moegliche Fehler kann ich nicht finden. Auch ohne -v tauchen manchmal
Zeilen wie:


Aug  2 21:51:17 v1 postfix/smtp[3584]: fatal: watchdog timeout
Aug  2 21:51:17 v1 postfix/smtp[3580]: fatal: watchdog timeout
Aug  2 21:51:17 v1 postfix/smtp[3578]: fatal: watchdog timeout
Aug  2 21:51:17 v1 postfix/smtp[3577]: fatal: watchdog timeout
Aug  2 21:51:17 v1 postfix/nqmgr[3591]: fatal: DCC55213: timeout receiving delivery status from transport: smtp
Aug  2 21:51:18 v1 postfix/master[23448]: warning: process /opt/postfix/libexec/smtp pid 3584 exit status 1
Aug  2 21:51:18 v1 postfix/master[23448]: warning: process /opt/postfix/libexec/smtp pid 3580 exit status 1
Aug  2 21:51:18 v1 postfix/smtp[3588]: fatal: watchdog timeout
Aug  2 21:51:18 v1 postfix/master[23448]: warning: process /opt/postfix/libexec/smtp pid 3578 exit status 1
Aug  2 21:51:18 v1 postfix/smtp[3585]: fatal: watchdog timeout
Aug  2 21:51:18 v1 postfix/smtp[3581]: fatal: watchdog timeout
Aug  2 21:51:18 v1 postfix/smtp[3579]: fatal: watchdog timeout
Aug  2 21:51:18 v1 postfix/master[23448]: warning: process /opt/postfix/libexec/smtp pid 3577 exit status 1
Aug  2 21:51:18 v1 postfix/master[23448]: warning: process /opt/postfix/libexec/nqmgr pid 3591 exit status 1
Aug  2 21:51:19 v1 postfix/smtp[3568]: fatal: watchdog timeout
Aug  2 21:51:19 v1 postfix/master[23448]: warning: process /opt/postfix/libexec/smtp pid 3588 exit status 1
Aug  2 21:51:19 v1 postfix/master[23448]: warning: process /opt/postfix/libexec/smtp pid 3585 exit status 1
Aug  2 21:51:19 v1 postfix/master[23448]: warning: process /opt/postfix/libexec/smtp pid 3581 exit status 1
Aug  2 21:51:19 v1 postfix/master[23448]: warning: process /opt/postfix/libexec/smtp pid 3579 exit status 1

auf, mit -v fallen mir nur die grossen Zeiten negativ auf:



Aug  3 23:59:10 v1 postfix/nqmgr[22471]: qmgr_active_feed: queue deferred
Aug  3 23:59:10 v1 postfix/nqmgr[22471]: qmgr_active_feed: deferred/BDA11105
Aug  3 23:59:10 v1 postfix/nqmgr[22471]: qmgr_active_feed: skip BDA11105 (2835 seconds)
Aug  3 23:59:10 v1 postfix/nqmgr[22471]: watchdog_start: 0x8074bd8
Aug  3 23:59:10 v1 postfix/nqmgr[22471]: qmgr_active_feed: queue incoming
Aug  3 23:59:10 v1 postfix/nqmgr[22471]: qmgr_active_feed: incoming/99364516
Aug  3 23:59:10 v1 postfix/nqmgr[22471]: qmgr_message_alloc: active 99364516

Alles grosser Mist :-( Ich habe Stunden gebraucht, um mit staendigen
"postfix stop && postsuper -s && postfix start" die queue zu leeren.

Koennen Sie mir aus Ihrer Erfahrung sagen, an welchen Parametern man drehen
sollte ??? Mein Ziel war es eigentlich, mit 2-3 solchen Kisten den ganzen
Mailverkehr unserer Uni zu filtern, mir kommen jetzt aber ernsthafte
Zweifel :-( Koennten evtl. auch irgendwelche Kernelparameter eine Rolle
spielen ??

Viele Gruesse

  Wolfram Greinert

> 
> -- 
> Ralf Hildebrandt (Im Auftrag des Referat V A)   Ralf.Hildebrandt at charite.de
> Charite Campus Virchow-Klinikum                 Tel.  +49 (0)30-450 570-155
> Referat V A - Kommunikationsnetze -             Fax.  +49 (0)30-450 570-916
> To correct all M$ Windows(tm) problems, only one small command is necessary:
> > format C: (then press y) 
> Bingo! Your Windows(tm) computer is now secure, stable, and every bit as
> useful as before.
> 


-- 
###########################################
#  Wolfram Greinert                       #
#  URZ der Uni Leipzig, Abteilung Netze   #
#  04109  Leipzig, Augustusplatz 10/11    #
#  Tel.:  +(0341) 97-33325                # 
#  email: greinert at rz.uni-leipzig.de      #
###########################################


Mehr Informationen über die Mailingliste Postfixbuch-users