[Eisfair] [E1] Mail: 2 fetchmail-Instanzen gleichzeitig?
Rolf Bensch
azubi at bensch-net.de
Fr Nov 15 09:50:41 CET 2019
Hallo Jürgen,
heute Morgen waren wieder 2 Fetchmail-Instanzen aktiv.
Am 29.10.19 um 08:38 schrieb Rolf Bensch:
> Hallo Jürgen,
>
> Am 28.10.19 um 19:45 schrieb Juergen Edner:
>> Hallo Rolf,
>>
>>>> wie hast Du den Parameter FETCHMAIL_DAEMON im mail-Paket gesetzt?
>>>> Es soll tatsächlich Anwender geben, die hier einen sehr kleinen
>>>> Intervall eingestellt haben, sodass z.B. beim Download von großen
>>>> Nachrichten die erste Instanz noch nicht beendet werden konnte und
>>>> schon eine neue Instanz gestartet wird.
>>>
>>> │ FETCHMAIL_DAEMON = 180
>>> │ FETCHMAIL_TIMEOUT = 90
>>>
>>> Seit Jahren unverändert und aktuell mit einer VDSL100-Leitung am Netz
>>
>> na ja, wie wir wissen hat die Aussage "seit Jahren unverändert" nur
>> bedingt Einfluss auf das Ergebnis, da die Dauer eines Abrufs von der
>> langsamsten Komponente in einer Übertragungskette abhängt ;-)
>
> In der letzten Nacht wurde erneut eine zusätzlich Instanz gestartet. Zum
> Erstellzeitpunkt des PID-Files hatte der Mailserver nichts zu tun.
>
>> Setze doch den Wert einmal von 180 auf 300 und schaue, ob sich das
>> Verhalten ändert.
Das hatte ich am 29.10. gesetzt und, weil es keine Problem mehr gab, am
10.11. wieder revidiert. Das lief jetzt 5 Tage störungsfrei, heute
wieder diese Doppelung.
n36l # ls -l /home/exim/.fetchmail.pid
-rw------- 1 exim trusted 9 Nov 15 00:00 /home/exim/.fetchmail.pid
n36l # cat /home/exim/.fetchmail.pid
3627
180
n36l # ps -ax | grep fetch
3627 ? SNs 1:23 /usr/bin/fetchmail -f /etc/fetchmail.conf
9298 ? SNs 8:33 /usr/bin/fetchmail -f /etc/fetchmail.conf
10053 pts/0 SN+ 0:00 /bin/sh /bin/grep fetch
Dem Zeitstempel des PID-Files zu urteilen, wurde um Mitternacht relaod
ausgeführt, dabei aber die bestehende Instanz nicht beendet.
> erledigt - auch wenn ich das hier geschriebene von Marcus durchaus
> nachvollziehen kann.
>
>> Du kannst natürlich auch die Logdatei analysieren und schauen, ob dort
>> etwas auffälliges zu finden ist. Beim Start wird normalerweise immer
>> "fetchmail: awakened at .." und nach dem Abruf "fetchmail: sleeping at
>> ..." geloggt.
2019-11-14 23:50:06 1iVNwE-0004WK-Cv Completed
2019-11-14 23:50:25 Start queue run: pid=20278
2019-11-14 23:50:25 End queue run: pid=20278
2019-11-14 23:55:25 Start queue run: pid=11198
2019-11-14 23:55:25 End queue run: pid=11198
2019-11-15 00:00:25 Start queue run: pid=2894
2019-11-15 00:00:25 End queue run: pid=2894
2019-11-15 00:00:28 pid 12923: SIGHUP received: re-exec daemon
2019-11-15 00:00:28 exim 4.92.3 daemon started: pid=12923, -q5m,
listening for SMTP on port 25 (IPv6 and IPv4) port 587 (IPv6 and IPv4)
2019-11-15 00:00:28 Start queue run: pid=3035
2019-11-15 00:00:28 End queue run: pid=3035
2019-11-15 00:00:28 pid 12979: SIGHUP received: re-exec daemon
2019-11-15 00:00:28 exim 4.92.3 daemon started: pid=12979, no queue
runs, listening for SMTPS on port 465 (IPv6 and IPv4)
2019-11-15 00:02:59 1iVO8h-0003j0-DI authenticated (1) /
authenticated_id (fetch-8pI1h)
2019-11-15 00:02:59 1iVO8h-0003j0-DI malware acl condition: clamd
/run/clamd : unable to connect to UNIX socket (/run/clamd): No such file
or directory
2019-11-15 00:02:59 1iVO8h-0003j0-DI H=localhost (n36l.rolf.lan)
[127.0.0.1] Warning: ACL "warn" statement skipped: condition test deferred
2019-11-15 00:02:59 1iVO8h-0003j0-DI malware acl condition: clamd
/run/clamd : unable to connect to UNIX socket (/run/clamd): No such file
or directory
2019-11-15 00:02:59 1iVO8h-0003j0-DI H=localhost (n36l.rolf.lan)
[127.0.0.1] Warning: ACL "warn" statement skipped: condition test deferred
2019-11-15 00:02:59 1iVO8h-0003j0-DI malware acl condition: clamd
/run/clamd : unable to connect to UNIX socket (/run/clamd): No such file
or directory
2019-11-15 00:02:59 1iVO8h-0003j0-DI H=localhost (n36l.rolf.lan)
[127.0.0.1] Warning: ACL "warn" statement skipped: condition test deferred
2019-11-15 00:02:59 1iVO8h-0003j0-DI malware acl condition: clamd
/run/clamd : unable to connect to UNIX socket (/run/clamd): No such file
or directory
2019-11-15 00:02:59 1iVO8h-0003j0-DI H=localhost (n36l.rolf.lan)
[127.0.0.1] Warning: ACL "warn" statement skipped: condition test deferred
2019-11-15 00:03:00 1iVO8h-0003j0-DI <= rolf at mydomain.de H=localhost
(n36l.rolf.lan) [127.0.0.1] P=esmtpa A=fixed_cram:fetch-8pI1h S=8270
id=832049.mmailer1000970333 at fritz.box
2019-11-15 00:03:00 1iVO8h-0003j0-DI => rolf <rolf at rolf.lan>
R=localuser_filtered T=local_delivery_filtered
2019-11-15 00:03:00 1iVO8h-0003j0-DI Completed
Die letzte Aktivität "mit Last" wurde um 23:56:06 beendet. Als nächstes
kam dann um 00:03:00 eine Statusmail der Fritzbox.
Ich finde hier keinen Zusammenhang zu Laufzeitproblemen und auch keinen
Grund weshalb eine Instanz nicht beendet werden könnte. Aktuell kann ich
die überzählige Instanz problemlos löschen:
n36l # kill 9298
n36l # ps -ax | grep fetch
3627 ? SNs 1:26 /usr/bin/fetchmail -f /etc/fetchmail.conf
23733 pts/0 SN+ 0:00 /bin/sh /bin/grep fetch
Huch: direkt danach ist das PID-File weg:
n36l # cat /home/exim/.fetchmail.pid
cat: /home/exim/.fetchmail.pid: No such file or directory
Das ist hier reproduzierbar:
n36l # /etc/init.d/mail reload
* Reloading exim configuration ... [ OK ]
* Starting Fetchmail daemon ... [ OK ]
n36l # cat /home/exim/.fetchmail.pid
8529 <- wieder da
180
n36l # ps -ax | grep fetch <- wieder 2 Instanzen
3627 ? SNs 1:26 /usr/bin/fetchmail -f /etc/fetchmail.conf
8529 ? SNs 0:00 /usr/bin/fetchmail -f /etc/fetchmail.conf
9742 pts/0 SN+ 0:00 /bin/sh /bin/grep fetch
n36l # kill 3627 <- alte Inst. gelöscht
n36l # cat /home/exim/.fetchmail.pid <- wieder weg
cat: /home/exim/.fetchmail.pid: No such file or directory
Abhilfe derzeit: _alle_ Instanzen löschen und ein "/etc/init.d/mail
reload" ausführen. Danach kann ich auch weitere "reload" ausführen, es
bleibt bei 1 Instanz.
Was kann ich hier noch tun? Siehst Du hier immer noch einen Zusammenhang
zu FETCHMAIL_DAEMON? Mir fällt das schwer.
Grüße Rolf
Mehr Informationen über die Mailingliste Eisfair