staging.inyokaproject.org

systemd ist für uns alle ein Stück weit Neuland. 😀 Wenn ich fetchmail starten will

systemctl start fetchmail

passiert nichts, d.h. ich finde fetchmail nicht in der Liste aller Prozesse, Fehlermeldung werden aber auch nicht ausgegeben.

Wie kann ich denn allgemein herausfinden, ob fetchmail etwas ausgegeben hat? Meine erste Anlaufstelle wäre

journalctl --since "hh:mm:ss"

gewesen, aber das enthält nichts wirklich Relevantes.

Kann ich das noch irgendwie anders untersuchen?

Syslog und ggf. andere Logs unter /var/log prüfen.

1
2

systemctl status fetchmail
journalctl -b -xep 0..4

Da sollte was drinstehen. Es sei denn fetchmail wurde mit no syslog und eigenem Logfile eingerichtet. Dann natürlich da rein gucken 😉

DJKUhpisse schrieb:

Syslog und ggf. andere Logs unter /var/log prüfen.

Ja, das habe ich als erstes gemacht. Mit systemd beschäftige ich mich nicht freiwillig! 😇

ralbuntu schrieb:

DJKUhpisse schrieb:

Syslog und ggf. andere Logs unter /var/log prüfen.

Ja, das habe ich als erstes gemacht. Mit systemd beschäftige ich mich nicht freiwillig! 😇

Und was ist dabei rausgekommen?

Im Paket gibt es laut https://packages.ubuntu.com/focal/amd64/fetchmail/filelist keine Systemd-Unit, sondern nur einen SysV-Init Datei (aus der dann eine Systemd-Unit generiert wird) - und in der wird die /etc/default/fetchmail eingelesen, in der die Variable START_DAEMON=yes gesetzt werden muss, damit der Dienst tatsächlich gestartet wird - hast du das schon gemacht?

ChickenLipsRfun2eat schrieb:

Da sollte was drinstehen. Es sei denn fetchmail wurde mit no syslog und eigenem Logfile eingerichtet. Dann natürlich da rein gucken 😉

Öhm:

## global options
set bouncemail
set no spambounce
set no syslog

*schäm* Ich habe immer nur auf den zweiten, Konto-spezifischen Teil geschaut ... 😳 Danke Dir!

Ich hab zwar keine Maildienste, aber ich bin auch talentiert darin Logfiles separat zu machen und dann nicht mehr dran zu denken. Und wir sind auch nicht die einzigen zwei beiden, die das können 😀

seahawk1986 schrieb:

Im Paket gibt es laut https://packages.ubuntu.com/focal/amd64/fetchmail/filelist keine Systemd-Unit, sondern nur einen SysV-Init Datei (aus der dann eine Systemd-Unit generiert wird) - und in der wird die /etc/default/fetchmail eingelesen, in der die Variable START_DAEMON=yes gesetzt werden muss, damit der Dienst tatsächlich gestartet wird - hast du das schon gemacht?

Ich habe mich zu früh gefreut, es funktioniert immer noch nicht.

Also, in /etc/default/fetchmail(!) ist START_DAEMON=yes. Darüberhinaus gibt es die Datei /etc/fetchmailrc(!), wo meine POP3-Daten drinstehen, was auch funktioniert.

cassiopeia:~# cat /etc/default/fetchmail 
# Declare here if we want to start fetchmail. 'yes' or 'no'
START_DAEMON=yes

cassiopeia:~# cat /etc/fetchmailrc
## global options
set postmaster "ralbuntu"
set bouncemail
set no spambounce
#set no syslog
set daemon 180

poll pop.1und1.de
proto POP3
user xxx
pass xxx
to   ralbuntu
mda  "procmail -d ralbuntu"
ssl

Grundsätzlich lief fetchmail die ganze Zeit, aber ich hatte ihn mit kill gestoppt, da ich eine Änderung an der fetchmailrc durchführen wollte. Nur das Neustarten funktioniert nun nicht mehr, auch ohne die Änderungen. Eine Fehlermeldung sehe ich nicht.

DJKUhpisse schrieb:

Ja, das habe ich als erstes gemacht. Mit systemd beschäftige ich mich nicht freiwillig! 😇

Und was ist dabei rausgekommen?

Leider nix: keine Einträge von fetchmail, weder im Journal noch in einem der Logs unter /var/logs.

Versuch mal in zwei Terminals/tmux gesplittet, o.ä. in einem Fenster journalctl -f mitlaufen zu lassen, während du im anderen systemctl restart fetchmail ausführst. Und zeige mal den Inhalt: systemctl cat fetchmail, damit Optionen sichtbar sind. Ggf. hängt da durch das killen noch ein socket in der Luft.

Oder:

set no syslog
set logfile /var/log/fetchmail.log

Dann hast es separat.

ralbuntu schrieb:

Grundsätzlich lief fetchmail die ganze Zeit, aber ich hatte ihn mit kill gestoppt, da ich eine Änderung an der fetchmailrc durchführen wollte. Nur das Neustarten funktioniert nun nicht mehr, auch ohne die Änderungen. Eine Fehlermeldung sehe ich nicht.

Damit könntest du die Prozesskontrolle durch Systemd unterlaufen haben (da gibt es einiges zu Beachten, wenn man Systemd-Units für SysV-Init Skripte automatisch generieren lässt: https://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/.

Was sagt denn

systemctl status fetchmail 

? Falls das den Service fälschlicherweise als laufend anzeigt, würde ich mal versuchen den Service zu stoppen und dann wieder zu starten, damit Systemd wieder der Meinung ist, dass es den Dienst kontrolliert:

systemctl stop fetchmail
systemctl start fetchmail 

- ggf. ist es insgesamt einfacher sich die benötigten Systemd-Dateien aus https://github.com/archlinux/svntogit-community/tree/packages/fetchmail/trunk zu holen)

seahawk1986 schrieb:

Was sagt denn

systemctl status fetchmail 

?

Also das ist ja echt interessant:

cassiopeia:~# systemctl status fetchmail
● fetchmail.service - LSB: init-Script for system wide fetchmail daemon
     Loaded: loaded (/etc/init.d/fetchmail; generated)
     Active: active (exited) since Fri 2021-09-10 09:39:39 CEST; 1 weeks 1 days ago
       Docs: man:systemd-sysv-generator(8)

Sep 10 09:39:38 cassiopeia systemd[1]: Starting LSB: init-Script for system wide fetchmail daemon...
Sep 10 09:39:39 cassiopeia fetchmail[1390]:  * Starting mail retriever agent:
Sep 10 09:39:39 cassiopeia fetchmail[1390]:    ...done.
Sep 10 09:39:39 cassiopeia systemd[1]: Started LSB: init-Script for system wide fetchmail daemon

Nach

cassiopeia:~# systemctl stop fetchmail
cassiopeia:~# systemctl start fetchmail

läuft er wieder! (Bin mir jetzt nicht ganz sicher, ob status den Service schon wiederbelebt, sieht ja so aus.)

Also herzlichen Dank an euch, da habe ich wieder was gelernt! Und so kompliziert ist systemd auch nicht.