Fetchmail via Cron spinnt

I.MC

Watt soll denn hier hin?
Hi zusammen,

seit Jahren hole ich externe E-Mails über fetchmail Einträge in Cron ab. Seitdem ich vor kurzem aber fetchmail aktualisiert habe und von 6.2 auf 6.3 gegangen bin im Basissystem... werden nicht mehr alle mails abgeholt. Einige bleiben einfach in der Pop 3 Fächern für Tage, einige werden abgegolt. Dies ist aber gerade nicht so eingestellt (-a Option) und funktienierte bisher auch korrekt.

Die Logs sagen nur folgendes, was ich aber bisher stets ignorieren konnte, da es trotzdem immer ging:

Code:
/var/log/.fetchmail.pid: Permission denied
fetchmail: lock creation failed.

Aufgerufen wird das ganze mehr periodisch je User über Cron mittels folgendem Eintrag:

Code:
*/2     *       *       *       *       benutzerxyz /usr/local/bin/fetchmail -s -a > /dev/null 2>&1
Logt man sich manuell als der jeweilige Benutzer ein und ruft fetchmail auf, so holt ein auch direkt korrekt alle Mails ab. Die Konfiguration befindet sich jeweils im Home-Verzeichnis der jeweiligen Benutzer.

Leider habe ich im Moment kaum Zeit und finde auf Anhieb keine Lösung. Wenn ihr was wisst, dann raus damit ;-).

Gruß, I.MC
 
Die Datei kann dort gar nicht existieren, da dies der Log Ordner des Systems ist. Da die Prozesse jeweils unter den Benutzer über Cron augerufen werden.... keine Schreibrechte. Wieso jedoch versucht fetchmail dort ein .pid File anzulegen? Das gehört doch eher in /tmp oder in das Home Verzeichnis....

Gruß, I.MC
 
Sollte die .pid nicht in /var/run stehen? Gut, mein Vorschlag ist jetzt evtl. keine Lösung aber vielleicht ein Versuch den Fehler zu finden. Teste mal getmail.

Ich habe jetzt fetchmail nicht mehr installiert (und kann deshalb nicht nachsehen), aber kannst du evtl. das Log-Level erhöhen? Wo ist der Eintrag des cronjobs? in /var/cron/tabs/username?
 
Hatte ich überlesen das das normal ist,

cron verschickt auch mails bei Problemen oder wenn Jobs nicht ausgeführt werden können,
 
I.MC hat Recht die permision denied ist weil er mit user Rechte ins /var/log/ zu schreiben versucht .
 
Seltsam ist ja, dass es einwandfrei funktioniert, wenn ich es manuell als der jeweilige User starte. Zudem sollte das .pid file einfach nicht an der Stelle zental auftauchen. Denn dann würden sich ggfs. alle cron fetchmail jobs gegenseitig blockieren. Meiner Kenntnis nach müssten die im jeweiligen Home Verzeichnis landen.
 
Hallo I.MC,

warum legst Du einen cronjob an? fetchmail kann das selber auch machen und Du umgehst dabei die Problematik mit den Permissions. Hier mal einen Auszug aus meiner fetchmail.conf:
Code:
set logfile /var/log/fetchmail.log

# alle 120 Sekunden abrufen
# ---------------------------------------------------------------------

set daemon 120

fetchmail startet als root:wheel, damit hat es Zugriff auf das Verzeichnis, und forked dann.

Viele Grüße

Jürgen
 
Es hatte damals einen Grund wieso ich das so gemacht hatte. Leider erinnere ich mich nicht mehr wirklich, aber es werden Mail verschiedenen Leute gepollt. Jeder hat also eigene Accounts und muss folglich selber seine Fetchmaileinstellungen verwalten könnten. Die sind in .fetchmailrc im home Verzeichnis.

Ich glaube das war der Grund wies ich es so gemacht hatte...

EDIT: Dennoch macht das keinen Sinn, wenn ich mich normal als der User einlogge und den selben Befehl absetzte, geht alles 1a wie früher. Auch wenn ich in Cron nur 1x fetchmail starten lassen, nix...
 
Zuletzt bearbeitet:
Du verwirrst mich das du sagst das wenn du dich einlogst als user das es funktioniert.
Zeig doch mal eine fetchmailrc.
 
Jemand auf -current hat das selbe Problem mit cronjobs unter 7.0.

Folgendes: Das /var/log kommt ueber die HOME Variable aus /etc/crontab, als normaler User in einer Login-Shell steht das auf HOME=/home/foo und darin hat der User Schreibrechte. Deshalb funktioniert fetchmail dann auch.

Die Frage ist nun, ob du die systemweite crontab verwendest, oder die User Crontab?


Edit: Wer lesen kann ... d.h. das Cronjob-Verhalten sich von 6.2 auf 6.3 (und 7.0) signifikant verändert hat und POLA verletzt. *Bitte* eröffne dafuer einen PR.
 
Zuletzt bearbeitet:
Mmh, das macht teilweise Sinn. Ich habe das auch schon gesehen. Ich verwende wie gesagt die systemweite crontab. Daher ist home = /var/log. Dennoch ist dieser Eintrag bereits seit 14? Jahren so. Das kann es nicht sein, es scheint etwas anderes geschehen zu sein. Leider muss ich gerade immer noch arbeiten. Zitat aus den Netz dazu: "I guess it would be due to a new shell forking which always reset $HOME. Thus, it only worked before by sheer
luck :)".

Hast du nähere Infos? Die bekl... Current Suchfunktion geht wie immer nur sehr bescheiden.

Gruß,I.MC
 
Zuletzt bearbeitet:
Ok, mit user crontabs geht es erwartungsgemäß korrekt. Alle Mails werden wieder abgeholt.
 
Das mit der geforkten Shell war nur ein Schuss ins Blaue. Ich denke inzwischen auch, das es nicht daran liegt. Ich habe versucht da unter 6.2 und 6.3 ein geändertes Environment zu finden, aber das klappt so einfach nicht :)
 
Zurück
Oben