fetchmail macht Probleme

[JoergLang]

Hallo,

neuerdings will Fetchmail nicht mehr wie es sollte. Ich starte per Cron Job fetchmail alle 5 Minuten an, der Eintrag in der .fetchmailrc ist folgender:
poll lang-iznang.de with proto POP3
user 'mein user' there with password '****' is <postfach> options keep
Das tut er auch, nur erhalte ich dann plötzlich Mails vom cronDaemon mit folgendem Inhalt:
fetchmail: SMTP connect to localhost failed
fetchmail: SMTP transaction error while fetching from lang-iznang.de

Leider kann ich damit absolut nichts anfangen, hat mir da bitte jemand einen Tipp?

Schonmal Danke für die Hilfe.

[tstiele]

Ich auch nicht. Aber grenz das Problem doch mal ein, indem Du Post auf anderem Weg abholst.
Gruss Thomas

[Der Gestreifte]

t:
[I]fetchmail: SMTP connect to localhost failed
Läuft denn ein MTA, an den fetchmail die Mails weitergeben könnte?

[JoergLang]

Ja sicher, postfix läuft, ein telnet localhost 25 klappt.

[Der Gestreifte]

Hm.
Ne Wirkliche Hilfe wird das jetzt nicht sein, aber "grep -i" mal in aller zur Verfügung stehenden Doku (nicht in der man, da war ich grad) zu fetchmail nach "hickup" oder"hiccup".
Ich kann mich dunkel an diese (sporadisch auftretende) Meldung erinnern.
Müsste sich mit dem Schalter "-m" umgehen lassen.

[JoergLang]

Die Frage ist eben woher oder warum die kommt.

[Der Gestreifte]

Die Frage ist eben woher oder warum die kommt.In der FAQ findet sich dazufolgendes:
R1. Fetchmail isn't working, and -v shows `SMTP connect failed' messages.
Fetchmail itself is probably working, but your SMTP port 25 listener is down or inaccessible.

The first thing to check is if you can telnet to port 25 on your smtp host (which is normally `localhost' unless you've specified an smtp option in your .fetchmailrc or on the command line) and get a greeting line from the listener. If the SMTP host is inaccessible or the listener is down, fix that first.

In Red Hat Linux 6.9, SMTP is disabled by default. To fix this, set "DAEMON=yes" in your /etc/sysconfig/sendmail file, then restart sendmail by running "/sbin/service sendmail restart".

If the listener seems to be up when you test with telnet, the most benign and typical problem is that the listener had a momentary seizure due to resource exhaustion while fetchmail was polling it -- process table full or some other problem that stopped the listener process from forking. If your SMTP host is not `localhost' or something else in /etc/hosts, the fetchmail glitch could also have been caused by transient nameserver failure.

Try running fetchmail -v again; if it succeeds, you had one of these kinds of transient glitch. You can ignore these hiccups, because a future fetchmail run will get the mail through.

If the listener tests up, but you have chronic failures trying to connect to it anyway, your problem is more serious. One way to work around chronic SMTP connect problems is to use --mda. But this only attacks the symptom; you may have a DNS or TCP routing problem. You should really try to figure out what's going on underneath before it bites you some other way.

We have one report (from toby@eskimo.com) that you can sometimes solve such problems by doing an smtp declaration with an IP address that your routing table maps to something other than the loopback device (he used ppp0).

We also have a report that this error can be caused by having an /etc/hosts file that associates your client host name with more than one IP address.

It's also possible that your DNS configuration isn't looking at /etc/hosts at all. If you're using libc5, look at /etc/resolv.conf; it should say something like

order hosts,bind

so your /etc/hosts file is checked first. If you're running GNU libc6, check your /etc/nsswitch.conf file. Make sure it says something like

hosts: files dns

again, in order to make sure /etc/hosts is seen first.

If you have a hostname set for your machine, and this hostname does not appear in /etc/hosts, you will be able to telnet to port 25 and even send a mail with rcpt to: user@host-not-in-/etc/hosts, but fetchmail can't seem to get in touch with sendmail, no matter what you set smtpaddress to.

We had another report from a Linux user of fetchmail 2.1 who solved his SMTP connection problem by removing the reference to -lresolv from his link line and relinking. Apparently in some older Linux distributions the libc bind library version works better.

As of 2.2, the configure script has been hacked so the bind library is linked only if it is actually needed. So under Linux it won't be, and this particular cause should go away. Vielleicht ist da was dabei.

[JoergLang]

If the listener seems to be up when you test with telnet, the most benign and typical problem is that the listener had a momentary seizure due to resource exhaustion while fetchmail was polling it -- process table full or some other problem that stopped the listener process from forking.

Das könnte hinkommen, wenn viel los ist, bekomme ich die Mails, sonst eigentlich nicht. Kann man da was an der prozesstable drehen? Es ist ja so gemeint, dass zuviele prozesse am laufen sind und er den listener einfach anhält. Also folglich mehr prozesse möglich machen, dann sollte das doch gehen oder?

[JoergLang]

Ich habe gesehen, dass in der master.cf folgende Zeile steht:
smtp-amavis unix - - n - 2 smtp -o smtp_data_done_timeout=1800 -o disable_dns_lookup=yes

Die 2 gibt dabei ja an, dass maxilam 2 Prozesse für amavis angestartet werden dürfen (wenn ich das richtig interpretiere). ich habe da einfach mal einen Strich ( - ) eingetragen für unlimited. jetzt will ich doch mal sehen ob das etwas bringt.