[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