Was war da am Mailserver los
Heute kamen im Laufe des Tages irgendwann keine Mails mehr an. Der Mailserver wurde nicht angerührt und vorweg, nun funktioniert er wieder, ohne, dass ich manuell Dateien editiert hätte. Ich verwende ein Script zum Mail abholen, das per cronjob ausgeführt wird. Das Script brachte nach manuellem Aufruf keine Ausgabe, also hatte ich mal das Script in Verdacht, dass es beschädigt wurde. Dem kann aber nicht so sein, da es nun ohne Änderung wieder funktioniert. In /var/log/mail fand ich einige Meldungen "deferred". d.h. die Mails waren also in einer Warteschlange und konnte nicht zugestellt werden. Ein fetchmail -vvv begann mit der Abfrage von Mails, es wurden einige empfangen und dann stand alles, sodass ich abbrach. Nachdem ich dann als nächsten Versuche auf Verdacht die Dienste postfix, amavis und spamd, pop3 stoppte und neu startete, funktionierte wieder alles, so weit ich es erkennen konnte. Nun würde mich interessieren, ob ich feststellen kann, warum es dazu kam. Wonach suche ich da am besten und wo, in /var/log/messages, in /var/log/mail? Al
Hallo,
Al Bogner
Heute kamen im Laufe des Tages irgendwann keine Mails mehr an. Der Mailserver wurde nicht angerührt und vorweg, nun funktioniert er wieder, ohne, dass ich manuell Dateien editiert hätte. [...] In /var/log/mail fand ich einige Meldungen "deferred". d.h. die Mails waren also in einer Warteschlange und konnte nicht zugestellt werden.
Ein fetchmail -vvv begann mit der Abfrage von Mails, es wurden einige empfangen und dann stand alles, sodass ich abbrach.
Nachdem ich dann als nächsten Versuche auf Verdacht die Dienste postfix, amavis und spamd, pop3 stoppte und neu startete, funktionierte wieder alles, so weit ich es erkennen konnte.
Nun würde mich interessieren, ob ich feststellen kann, warum es dazu kam. Wonach suche ich da am besten und wo, in /var/log/messages, in /var/log/mail?
Läuft bei dir der Portmapper? Ich hatte vor einigen Tagen testweise den portmapper abgestellt und hatte daraufhin ähnliche Ergebnisse mit deferred Mails, aber auch mit Imap. Es hat teilweise 20 Minuten gedauert, bis das System wieder ansprechbar war. Es gab einige Error Meldungen in /var/log/messages: localhost: RPC: Port mapper failure - RPC: Unable to receive Nachdem ich den Portmapper wieder gestartet hatte gab es keine Probleme mehr. Ich muß gestehen, daß ich keinen ursächlichen Zusammenhang zwischen deferred mails, Imap und portmapper herstellen kann, die Erkenntnis ist nur try and error, ohne methodische Analyse. -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:8C183C8622115328
Am Montag, den 13.09.2004, 18:45 +0200 schrieb Al Bogner:
Ein fetchmail -vvv begann mit der Abfrage von Mails, es wurden einige empfangen und dann stand alles, sodass ich abbrach.
Schau mal in top und ps -faux nach, ob vielleicht jede Mail einzeln den spamassassin (oder vergleichbares) triggert. Dann hast du plötzlich 20,30,40 spamassassins[,procmails, amavis,...] auf. Das kann den Prozess des Mailabholens abschiessen, weil der Speicher zuläuft. Das perfide daran ist, daß sich die Mails nun aufstauen und die Chance eines Crashes immer größer wird. Schaltet man spamassassin [...] kurz aus, werden alle Mails prozessiert und das Problem ist erstmal weg - bis vielleicht mal wieder irgendein Listenserver [, Spammer, vacation, ...] Schluckauf hat und dich erst gar nicht versorgt und dann zuballert. Ich hatte dieses Problem und habe es nicht geschafft, spamassassin als Daemon aus procmail anzusprechen. Ich habe daher die Realität dem Problem angepasst und bei meinem fetchmail ein Limit von 25 Mails "pro fetch" eingestellt. Das läuft erstmal. Gruß, Ratti -- -o) fontlinge | Fontmanagement for Linux | Schriftenverwaltung in Linux /\\ http://freshmeat.net/projects/fontlinge/ _\_V http://www.gesindel.de https://sourceforge.net/projects/fontlinge/
Am Montag, 13. September 2004 20:39 schrieb Joerg Rossdeutscher:
Am Montag, den 13.09.2004, 18:45 +0200 schrieb Al Bogner:
Ein fetchmail -vvv begann mit der Abfrage von Mails, es wurden einige empfangen und dann stand alles, sodass ich abbrach.
Schau mal in top und ps -faux nach, ob vielleicht jede Mail einzeln den spamassassin (oder vergleichbares) triggert. Dann hast du plötzlich 20,30,40 spamassassins[,procmails, amavis,...] auf. Das kann den Prozess des Mailabholens abschiessen, weil der Speicher zuläuft.
Das perfide daran ist, daß sich die Mails nun aufstauen und die Chance eines Crashes immer größer wird.
Es gab nie einen Crash. Ich kann an den Rechner (bequem) nur per ssh. Nach einem Reboot hatte sich nichts geändert. No Mail. Allerdings hat bei dem fetchmail, das mit ^C abgebrochen wurde, ein reboot relativ lange gedauert. Ich schätze mal, dass an die 100 Mails in der Schlange waren, da hatte ich schon viel mehr auf einen Schlag abzuholen. Der Mailserver ist zwar nur ein Celeron 466 (448MB RAM) , aber einfache Befehle wie df, waren normal schnell. Zur Zeit kommen nicht so viele Mails an, aber ich denke, dass da nicht für jedes Mail ein Prozess gestartet wird. Bei ein paar Mails sah ich: root 7362 0.0 0.3 4108 1412 ? Ss 18:00 0:01 /usr/lib/postfix/master postfix 7370 0.0 0.3 4372 1632 ? S 18:00 0:01 \_ qmgr -l -t fifo -u postfix 15210 0.0 0.3 4220 1440 ? S 20:45 0:00 \_ pickup -l -t fifo -u vscan 7497 0.0 7.3 36528 33056 ? Ss 18:00 0:03 amavisd (master) vscan 15698 0.4 7.6 38044 34596 ? S 21:01 0:09 \_ amavisd (child) vscan 16829 0.3 7.4 37052 33648 ? S 21:31 0:01 \_ amavisd (child) root 7528 0.0 5.1 27020 23460 ? Ss 18:00 0:02 /usr/sbin/spamd -d -c -a -L -s facility Al
participants (3)
-
Al Bogner
-
Dieter Kluenter
-
Joerg Rossdeutscher