[Eisfair] [E64]: fetchmail-loader wird beendet

Do Dez 19 17:13:57 CET 2024

Hallo Jürgen,

Am 19.12.24 um 11:36 schrieb Juergen Edner:
> Hallo Rolf,
> 
>> "fetchmail_loader" und "sleep" sind nicht mehr vorhanden, entsprechend werden keine eMails mehr abgeholt. Auch nach einem "start mail service" bleibt fetchmail inaktiv. Nach "stop mail service" -> "start mail service" ist der Cron-Job wieder aktiv. Eine Fehlermeldung gab es in diesem Umfeld nicht.
>>
>> Habe nur ich (mal wieder) dieses Problem oder kann das noch jemand bestätigen?
> wenn dies ein generelles Problem wäre, hätte sich meines Erachtens schon längst jemand diesbezüglich gemeldet.

Hmmm, ich habe seit mind. einem halben Jahr immer mal wieder die Situation gehabt, dass fetchmail nicht automatisiert Mails abholt. Nach einem Neustart des Dienstes versieht fetchmail aber immer tadellos seine Aufgabe. Jetzt stelle ich fest, dass _nur_ das manuelle Abholen von eMails den Automatismus stoppt. Ich denke nicht, dass das jedem Admin auffällt.

> Wenn der Loader-Prozess nicht gestartet wird, rufe im Anschluss bitte einmal den folgenden Befehl auf:
> 
> /var/lib/mail/mail --debug start

Ausgangslage nach Neustart des PC:

   root at eis64-3 (~)# systemctl status mail
   ● mail.service
        Loaded: loaded (/etc/init.d/mail; generated)
        Active: active (running) since Thu 2024-12-19 16:38:32 CET; 8min ago
          Docs: man:systemd-sysv-generator(8)
       Process: 5637 ExecStart=/etc/init.d/mail start (code=exited, status=0/SUCCESS)
         Tasks: 3 (limit: 4801)
           CPU: 550ms
        CGroup: /system.slice/mail.service
                ├─5676 /usr/sbin/exim -bd -q30m -om -oP /run/exim.pid
                ├─5718 /bin/sh /usr/bin/fetchmail-loader start
                └─5886 sleep 900

   Dec 19 16:38:20 eis64-3 systemd[1]: Starting mail.service...
   Dec 19 16:38:21 eis64-3 mail[5637]:  * Starting SMTP server ...
   Dec 19 16:38:23 eis64-3 mail[5637]: [26B blob data]
   Dec 19 16:38:25 eis64-3 mail[5637]:  * Starting Fetchmail daemon ...
   Dec 19 16:38:26 eis64-3 su[5721]: (to exim) root on none
   Dec 19 16:38:26 eis64-3 su[5721]: pam_unix(su-l:session): session opened for user exim(uid=488) by (uid=0)
   Dec 19 16:38:26 eis64-3 mail[5637]: [26B blob data]
   Dec 19 16:38:27 eis64-3 su[5721]: pam_unix(su-l:session): session closed for user exim
   Dec 19 16:38:32 eis64-3 systemd[1]: Started mail.service.

Hier führe ich dann "[8] Force mail request" aus. Direkt danach:

   root at eis64-3 (~)# systemctl status mail
   ● mail.service
        Loaded: loaded (/etc/init.d/mail; generated)
        Active: active (running) since Thu 2024-12-19 16:38:32 CET; 9min ago
          Docs: man:systemd-sysv-generator(8)
       Process: 5637 ExecStart=/etc/init.d/mail start (code=exited, status=0/SUCCESS)
         Tasks: 1 (limit: 4801)
           CPU: 552ms
        CGroup: /system.slice/mail.service
                └─5676 /usr/sbin/exim -bd -q30m -om -oP /run/exim.pid

   Dec 19 16:38:20 eis64-3 systemd[1]: Starting mail.service...
   Dec 19 16:38:21 eis64-3 mail[5637]:  * Starting SMTP server ...
   Dec 19 16:38:23 eis64-3 mail[5637]: [26B blob data]
   Dec 19 16:38:25 eis64-3 mail[5637]:  * Starting Fetchmail daemon ...
   Dec 19 16:38:26 eis64-3 su[5721]: (to exim) root on none
   Dec 19 16:38:26 eis64-3 su[5721]: pam_unix(su-l:session): session opened for user exim(uid=488) by (uid=0)
   Dec 19 16:38:26 eis64-3 mail[5637]: [26B blob data]
   Dec 19 16:38:27 eis64-3 su[5721]: pam_unix(su-l:session): session closed for user exim
   Dec 19 16:38:32 eis64-3 systemd[1]: Started mail.service.

"fetchmail-loader" und "sleep" sind weg. Aber:

   root at eis64-3 (~)# /usr/bin/fetchmail-loader status
   fetchmail-loader running with Process ID(s)  7570

Irgendwo läuft noch eine Instanz. Wie empfohlen:

   root at eis64-3 (~)# /var/lib/mail/mail --debug start
   root at eis64-3 (~)# systemctl status mail
   ● mail.service
        Loaded: loaded (/etc/init.d/mail; generated)
        Active: active (running) since Thu 2024-12-19 16:38:32 CET; 10min ago
          Docs: man:systemd-sysv-generator(8)
       Process: 5637 ExecStart=/etc/init.d/mail start (code=exited, status=0/SUCCESS)
         Tasks: 1 (limit: 4801)
           CPU: 552ms
        CGroup: /system.slice/mail.service
                └─5676 /usr/sbin/exim -bd -q30m -om -oP /run/exim.pid

   Dec 19 16:38:20 eis64-3 systemd[1]: Starting mail.service...
   Dec 19 16:38:21 eis64-3 mail[5637]:  * Starting SMTP server ...
   Dec 19 16:38:23 eis64-3 mail[5637]: [26B blob data]
   Dec 19 16:38:25 eis64-3 mail[5637]:  * Starting Fetchmail daemon ...
   Dec 19 16:38:26 eis64-3 su[5721]: (to exim) root on none
   Dec 19 16:38:26 eis64-3 su[5721]: pam_unix(su-l:session): session opened for user exim(uid=488) by (uid=0)
   Dec 19 16:38:26 eis64-3 mail[5637]: [26B blob data]
   Dec 19 16:38:27 eis64-3 su[5721]: pam_unix(su-l:session): session closed for user exim
   Dec 19 16:38:32 eis64-3 systemd[1]: Started mail.service.

Bringt auch kein "fetchmail-loader" und "sleep" an den Start.

> Anschließend solltest Du in /tmp eine Datei mail-init-start-traceXXXX.log finden, die eventuell einen Hinweis darauf enthält, warum der Dienst nicht neu gestartet wird.

Auszugsweise der Start von fetchmail-loader:

   + sleep 2
   + start_fetchmail
   + local _sf_fm_delay=
   + local _sf_fm_file=
   + case "$1" in
   + '[' yes = yes -a 3 -gt 0 ']'
   + check_pid_file fetchmail-loader /run/fetchmail-loader.pid
   + local _cpf_procname=fetchmail-loader
   + local _cpf_pidfile=/run/fetchmail-loader.pid
   + local _cpf_delflag
   + local _cpf_pidnum
   + local _cpf_pidlist
   + '[' -e /run/fetchmail-loader.pid -a -f /run/fetchmail-loader.pid ']'
   + _cpf_delflag=1
   ++ cat /run/fetchmail-loader.pid
   ++ cut '-d ' -f1
   ++ tr -s '\n' ' '
   + _cpf_pidnum=7570
   ++ ps -Ae -o cmd,pid
   ++ rev
   ++ grep '^[a-z/]*fetchmail-loader'
   ++ cut '-d ' -f1
   ++ rev
   + _cpf_pidlist=
   + '[' 1 -eq 1 ']'
   + rm -f /run/fetchmail-loader.pid
   + /usr/bin/fetchmail-loader status --fm-start-1
   + grep -q 'is not running'
   + '[' 1 -eq 0 ']'
   + '[' 1 -eq 1 ']'
   + start_dovecot

.. bei Bedarf auch gerne das vollständige trace-log.

Vielleicht auch im Zusammenhang: setze ich in der Config "MAIL_DO_DEBUG = true" bleibt der Start bei "* Starting mail.service ...
" hängen. Im Status dann:

   root at eis64-3 (~)# systemctl status mail
   ● mail.service
        Loaded: loaded (/etc/init.d/mail; generated)
        Active: activating (start) since Thu 2024-12-19 17:03:51 CET; 1min 7s ago
          Docs: man:systemd-sysv-generator(8)
     Cntrl PID: 6591 (mail)
         Tasks: 1 (limit: 4801)
           CPU: 49.637s
        CGroup: /system.slice/mail.service
                └─6591 /bin/sh /etc/init.d/mail start

   Dec 19 17:04:36 eis64-3 mail[6591]: Do you want to debug the (S)MTP daemon or (d)isable debugging (s,d)? WRONG INPUT! Please answer 's' or 'd'!
   Dec 19 17:04:36 eis64-3 mail[6591]: Do you want to debug the (S)MTP daemon or (d)isable debugging (s,d)? WRONG INPUT! Please answer 's' or 'd'!
   ...

Wenn ich dann "MAIL_DO_DEBUG" wieder auf "no" setzen möchte:

root at eis64-3 (~)# setup

   The package edit menu for mail is currently
   used by another instance.
   Please exit this other instance to use package edit here.

... geht das daher nur manuell über /etc/config.d/mail.

Das ist jetzt kein gravierendes Problem weil fetchmail ansonsten tadellos arbeitet und im Regelbetrieb auch nicht einfach stehen bleibt. Vielleicht findet es aber den Weg auf die Todo-Liste - oder auf meiner Kiste ist mal wieder etwas faul und ich muss dem auf den Grund gehen.

Grüße

Rolf