(gelöst) fetchmailrc: set daemon 600

[michaa7]

Obwohl mein als user laufender fetchmail daemon wie im Betreff schon erwähnt (fetchmailrc: set daemon 600) nur alle 10 Minuten abfragen soll, sehe ich unter htop ein "....daemon 300" was auch mit der Ausgabe im journal übereinstimmt: es wird alle 5 Minuten abgefragt. Eine Änderung oder Verdoppelung in der ~/.fetchmailrc bewirkt gar nichts.

Wirkt hier irgend ein default (was ich nicht gefunden habe), hat hier jemand ähnliche Abweichungen? Das ist einfach eine Rückfrage bevor ich einen bugreport erstelle.

[chrbr]

Eine Änderung oder Verdoppelung in der ~./fetchmailrc bewirkt gar nichts.

Wahrscheinlich is das nur ein Tippfehler, oder? Die Datei sollte so heissen:

Code: Alles auswählen

~/.fetchmailrc

[michaa7]

Sehr aufmerksam, mir ist erst gar nicht aufgefallen was du meinst , ja ein Tippfehler, habe es korrigiert. Danke.

[chrbr]

Was sagt denn bei Dir die Ausgabe wie unten?

Code: Alles auswählen

> ps aux|grep fetchmail
fetchma+  335876  9.2  0.1  14188  9832 ? S 15:37 0:00 /usr/bin/fetchmail --syslog --fetchmailrc /var/lib/fetchmail/fetchmailrc-imap

Ist in einem Startskript möglicherweise wie bei mir ein anderes fetchmailrc konfiguriert?
Oder ist -d 600 als Option angegeben?

[michaa7]

Danke dass du dich einklinkst.

BTW: Debian/sid(uction) tagesaktuell

~$ ps aux|grep fetchmail
mh 5667 0.0 0.1 59604 9728 ? Ss 16:23 0:00 fetchmail --nodetach --daemon 300
mh 31465 0.0 0.0 49628 2304 pts/0 S+ 16:28 0:00 grep fetchmail

Meine ~/.fetchmailrc (editiert)

set daemon 600

poll mail.xxxxxxxxx.de proto pop3 user "ab123456@post.xxxxxxxxxxx.de" password "XYZ123456" is mh here ssl

fetchtmail läuft, wie es soll, im user Kontext. Es wird in der Nutzer Autostartdatei "Startup" meines Fluxbox WMs über

Code: Alles auswählen

/usr/bin/fetchmail &

gestartet.

Was ich nicht verstehe ist:

- Egal was ich oben als Intervall eingebe, ich habe auch 1200 versucht, im journal sehe ich alle 5 Minuten den poll wie es ja den 300 entspricht wie sie ps aus dem system gefischt hat.

Es gibt einen fetchmail.service, der wohl automatisch von systemd angelegt wurde, obwohl in der systemweiten config von fetchmail unter /etc/default/fetchmail steht
"# Declare here if we want to start fetchmail. 'yes' or 'no'
START_DAEMON=no" . Entsprechend gibt es /etc/init.d/*fetchmail, wozu auch immer.
Dies stammt vermutlich noch aus präsystemd Zeiten.
Der service war aktiv, den habe ich disabled was hinsichtlich der 5-minuten polls nichts ändert.
Nun ist der service zwar inaktiv, wird aber dennoch geladen. Das alles wirkt sich auf die im Nutzerkontext laufende Instanz *nicht* aus.
Ich habe keine weitere fetchmail config gefunden, es bleibt ein Rätsel woher diese Wert 300 stammt.

[chrbr]

Ich habe bei mir mal nach den "-d 300" gesucht und bin 2x fündig geworden:

Code: Alles auswählen

# find /usr -type f|grep fetchmail|xargs grep "\-d 300"
/usr/share/doc/fetchmail/contrib/login:    /usr/local/bin/fetchmail -d 300

# find /etc -type f|grep fetchmail|xargs grep "\-d 300"
/etc/init.d/fetchmail:          OPTIONS="$OPTIONS -d 300"

Entweder Du probierst aus was passiert, wenn Du an den Stellen die 300 änderst. Eine andere Möglichkeit wäre dem Befehl in fluxbox ein "-d 600" anzuhängen.

[michaa7]

Danke. Wenn man sich auskennt wie man auf der Kommandozeile sucht dann findet man auch etwas

Das Ergebnis ist bei mir Identisch mit deinen Suchkommandos. Das heißt aber wohl, dass zumindes das Setting für das Intervall in ~/.fetchmailrc nicht beachtet wird.
Da scheint das setting in /usr/share/doc/fetchmail/contrib/login Vorang zu haben, was zudem unter der Bedingung steht, dass ~/.fetchmailrc existiert Ja, ich teste das mal im FB Autostart.

Hast du auch diesen systemd service? Es ist merkwürdig dass es diesen gibt, es aber für fetchmail im Nutzerkontext ohne Bedeutung ist.

[michaa7]

Ich habe jetzt fetchmail gepurget und nach einem reboot neu installiert. Ich glaubte dass auf Grund der recht alten Konfiguration über mehrere fetchmail Versionen mit meiner Erinnerung nach mindestens einem Update zu dem es Warnungen über potentiell holprigen Übergängen gab die Konfiguration irgendwo nen Knoten haben könnte.

Zunächst war ich danach verzweifelt weil nichts mehr zu funktionieren schien, ich insbesondere überhaupt keine Meldung mehr im Journal zu Gesicht bekam. Ein letzte Blick in ~/.fetchmail log zeigte mir jedoch dass die Meldungen nun, wie eigentlich auch zuvor gewünscht, aber nicht geschehen, nun dort landen. Finde ich eigentlich gut so.

In soweit ist dieses Problem gelöst, weil auch das gewählte Intervall nun stimmt.

Danke, zumindest habe ich mit deiner Hilfe etwas in die eingeweide der fetchmail Funktion schauen können. Das log zeigt mir allerdings ein weiters Problem für das ich einen neuen thread öffne. Vllt kannst du dort auch mal reinschauen.

[chrbr]

Zu dem Service: Du startest ja fetchmail nicht von systemd aus, sondern über einen Eintrag in Fluxbox. Da interessiert der Eintrag in /etc/default/fetchmail wohl nicht. Bei mir steht dort

Code: Alles auswählen

# This file will be used to declare some vars for fetchmail
#
# Uncomment the following if you don't want localized log messages
# export LC_ALL=C

# If you want to specify any additional OPTION to the start
# scripts specify them here
# OPTIONS=...

# Declare here if we want to start fetchmail. 'yes' or 'no'
START_DAEMON=yes

Das könnte durchaus noch Original sein. Bei mir wird fetchmail allerdings auch über systemd gestartet.

[michaa7]

...
Das könnte durchaus noch Original sein. Bei mir wird fetchmail allerdings auch über systemd gestartet.

Das wird aber nur für multiuser empfohlen.

Wie auch immer, ich habe fetchmail.service disabled. Der im Nutzerkontext gestartete daemon reicht und tut was er soll.