AW: Regelmässiger Absturz des Postfix-Servives

[Uwe Drießen]

Hallo Andreas 
Ich hab das ganze mal meiner trainierten KI einfach hingeworfen .... und ich hab ihr schon gesagt fasse dich kurz :-) 

Das ist scheinbar kein Postfix Problem 
nach Sichtung der Logs sieht es für mich eher nicht nach einem primären Postfix Problem aus.

Zum Absturzzeitpunkt fällt zuerst systemd-journald mit Watchdog Timeout auf, zudem werden system.journal und user-5000.journal als beschädigt bzw. unsauber beendet gemeldet. Erst danach folgt bei Postfix Main process exited, status=14/ALRM.

Auffällig ist außerdem kurz davor eine größere Zahl paralleler Verbindungen auf smtps Port 465 mit SSL_accept error und lost connection after CONNECT. Das waren in diesen Minuten zwar keine echten Mailtransfers, aber durchaus viele TLS Handshakes und Logeinträge durch Scanner oder Bots.

Mein derzeitiger Verdacht ist daher:

primär ein Problem mit journald bzw. I/O oder Logging
verstärkt durch viele kurze Verbindungen auf 465
Postfix dann als Folgeschaden mit Timeout ALRM

Als nächste Schritte würde ich daher eher journalctl --verify, dmesg, mögliche I/O Fehler, Coredumps sowie testweise eine Begrenzung der Prozesse bzw. Verbindungen auf smtps und submission prüfen, bevor ich Postfix selbst als Hauptursache annehme.

Was die Logs sagen
journald war kaputt bzw. hing
systemd-journald.service: Watchdog timeout
system.journal corrupted or uncleanly shut down
user-5000.journal corrupted or uncleanly shut down
Postfix wurde mit Signal ALRM beendet
postfix.service: Main process exited, code=killed, status=14/ALRM
Zur selben Zeit massig Verbindungsversuche auf smtps 465
viele connect from unknown[...]
viele SSL_accept error ... lost connection

Das sind typische Bot und Scanner Verbindungen. Die wollen nicht sauber Mail schicken, die klopfen nur an die Tür und rennen wieder weg. Das allein ist noch kein Weltuntergang. Aber es produziert Prozesse, TLS Handshakes, Logeinträge und Dreck im Stall.

Scannerlast auf 465
plus
viel Logging / I/O Problem / journald hängt
gleichzeitig
Postfix oder einer seiner Kinder bleibt irgendwo fest
und dann kommt ALRM als Folgeschaden, nicht als eigentliche Ursache.

Anders gesagt:
Nicht die Mailübertragung ist gestorben, sondern eher das Drumherum im Betriebssystem hat angefangen zu stolpern.
1. journald / Storage / I/O Hänger

Das ist mein Hauptverdacht.

Warum:
Journal korrupt
Watchdog Timeout
Startoperation von journald timed out
Logreihenfolge ist nach Journald Absturz schon halb Kartoffelsuppe

Prüfen:

journalctl --verify
systemctl status systemd-journald
dmesg -T | egrep -i 'error|ext4|xfs|blk|nvme|scsi|hung|oom|watchdog'

Wenn da I/O Fehler, Hänger oder Block Layer Theater auftauchen, hast du den Hasen.

2. Scannerflut auf Port 465

Dein smtps hängt offen im Internet und wird beackert wie ein Acker im Frühjahr.

Die vielen:

connect from unknown
SSL_accept error
lost connection after CONNECT

zeigen, dass Bots auf 465 feuern.
Wenn genug parallel kommen, hast du:

viele smtpd Prozesse
TLS Aufwand
Logging Aufwand
möglicher Stress auf Dovecot Auth Socket, Milter, DNS, Journal

Submission 587 und SMTPS 465 für echte Benutzer offen lassen ist normal.
Aber man muss sie hart begrenzen.

3. Ein Nebenprozess blockiert Postfix
Mögliche Kandidaten:
milter auf localhost:11332
dovecot auth Socket
MySQL Lookups
DNSBL / DNS Auflösung
postscreen eher nur Port 25, also hier weniger verdächtig

Dein milter_default_action = tempfail ist okay für Mailfluss, aber wenn der Milter oder Logging klemmt, kann das trotzdem Chaos machen.

A. Journald aufräumen
systemctl stop postfix
systemctl stop systemd-journald

mv /var/log/journal/4063617fe39349249b8031de6b7b3d12/system.journal \
   /var/log/journal/4063617fe39349249b8031de6b7b3d12/system.journal.bad.$(date +%F_%T) 2>/dev/null

mv /var/log/journal/4063617fe39349249b8031de6b7b3d12/user-5000.journal \
   /var/log/journal/4063617fe39349249b8031de6b7b3d12/user-5000.journal.bad.$(date +%F_%T) 2>/dev/null

systemctl start systemd-journald
journalctl --flush
systemctl start postfix

journalctl --verify

B. 465 und 587 härter einschnüren

Du hast auf smtps und submission aktuell kein Prozesslimit gesetzt.
Dann greift der Default. Das ist oft zu großzügig.

In master.cf würde ich für beide Dienste testweise bremsen:

smtps      inet  n       -       -       -       20      smtpd
submission inet  n       -       -       -       20      smtpd

Noch sauberer mit Rate Limits und Anvil.

Zusätzlich:

smtpd_client_connection_count_limit = 10
smtpd_client_connection_rate_limit = 30
anvil_rate_time_unit = 60s

C. Fail2ban oder nftables auf 465 und 587

Wer auf SMTPS nur connectet und sofort wieder stirbt, ist selten Tante Erna mit Outlook.

Du kannst diese Kandidaten schön absägen:

viele kurze Fehlverbindungen
SASL Fehlschläge
verdächtige Verbindungsrate

Wenn du schon Fail2ban hast, baue dafür einen eigenen Jail für postfix-smtps.


D. Testweise Milter rausnehmen

Nur zum Eingrenzen. Nicht als Dauerlösung.

postconf -e 'smtpd_milters='
postconf -e 'non_smtpd_milters='
systemctl reload postfix

Wenn die Kiste dann stabil bleibt, sitzt der Wurm eher beim Milter.

Danach wieder zurückdrehen.

E. Dovecot Auth Socket prüfen

Weil smtps und submission beide SASL via Dovecot nutzen.

Prüfen:

ss -lx | grep auth_dovecot
systemctl status dovecot
journalctl -u dovecot --since "2026-03-27 21:00:00"

Wenn Dovecot Auth hängt, stauen sich deine MUA Ports.

Die sinnvollsten Prüfkommandos jetzt

Einmal diese Batterie, ohne Schnickschnack:

systemctl cat postfix
postconf default_process_limit
postconf smtpd_client_connection_count_limit
postconf smtpd_client_connection_rate_limit
postqueue -p
postfix status
journalctl -u postfix --since "2026-03-27 21:00:00" --until "2026-03-27 21:45:00"
journalctl -u systemd-journald --since "2026-03-27 21:00:00" --until "2026-03-27 21:45:00"
journalctl --verify
dmesg -T | egrep -i 'oom|killed process|watchdog|hung task|ext4|xfs|blk|nvme|scsi|i/o'
ss -tnp | egrep ':465|:587|:25'

Und ganz wichtig:

coredumpctl list | grep -E 'postfix|journald'

Wenn für postfix oder journald ein Core da ist, wird es plötzlich sehr viel weniger mystisch.

Primärproblem: systemd-journald bzw. I/O/Journal Problem
Verstärker: Scannerflut auf 465
Folgeschaden: Postfix Master oder Teilprozess läuft in Hänger/Timeout und stirbt mit ALRM

Also:
Der Briefträger ist nicht an einem Liebesbrief gestorben, sondern weil die Straße voller Schlamm war und draußen zehn Betrunkene gleichzeitig Sturm geklingelt haben.

Mit freundlichen Grüßen

Uwe Drießen
--
Software & Computer

Netzwerke, Server. 
Wir vernetzen Sie und Ihre Rechner !

Uwe Drießen
Lembergstraße 33
67824 Feilbingert

Tel.: 06708660045 
Mobil 01726688122
" Ich bekomme so langsam Pickel wie die DIGITALIESIERUNG und KI MEHR Arbeit verursacht weil es Unternehmen nicht hinbekommen diese so zu GESTALTEN das diese den MENSCHEN ENTLASTET."
"Wissen macht den Unterschied zu Titel, Titel kosten - Wissen verdient."
"Digitalisierung löst KEINE Probleme, wer nicht Analog arbeiten kann wird es auch digital nicht können, Digitalisierung deckt gnadenlos jedes Problem auf."
"wenn Digitalisierung den Aufwand zur Analogen Arbeitsweise erhöht, den Gewinn schmälert dann wird es Zeit zur Analogen Arbeitsweise zurückzukehren"
"Programmierer müssen lernen wie Menschen denken. "
"Digitalisierung ist die Intelligente Art erforderliche Arbeit auf Kunden zu übertragen. ("
"Digitalisierung darf nicht zur Entmündigung führen."
" Es gibt über 2000 Jahre alte Papierdokumente, 10000 Jahre alte Steintafeln und wie alt ist das älteste elektronische Dokument?"