SEPPmail Appliance 15.0.4.1: Hotfix gegen PID-Erschöpfung in der RuleEngine
Am 28. April 2026 hat SEPPmail das Hotfix-Release 15.0.4.1 für seine Appliance-Linie veröffentlicht. Es behebt einen Bug aus dem Patch 15.0.4 vom 24. April, der in Produktivumgebungen die ganze Appliance einfrieren konnte. Wer 15.0.4 bereits ausgerollt hat, sollte das Update zeitnah einspielen. [1][2]
Der Bug: fehlendes waitpid in der RuleEngine
Die RuleEngine ist die Komponente, in der SEPPmail die konfigurierten Mail-Verarbeitungsregeln gegen ein- und ausgehende Nachrichten auswertet. Sie nutzt dafür das klassische POSIX-Pattern fork()/waitpid(): Der Elternprozess erzeugt per fork() einen Kindprozess für die Teilaufgabe und holt sich anschließend mit waitpid() den Exit-Status zurück.
In Version 15.0.4 fehlte dieser zweite Aufruf. SEPPmail beschreibt das Verhalten in den Extended Release Notes wörtlich so: [1]
Failing to callwaitpidafter aforkcaused the forked processes to remain running in the background. This eventually led to the user exhausting the maximum number of available PIDs and preventing any further processes from being started, so that the system was effectively dead.
Ohne waitpid() bleiben die Kindprozesse in der Prozess-Tabelle und belegen weiterhin je einen PID-Slot. Über die Laufzeit füllt sich das Pro-User-Prozess-Limit (RLIMIT_NPROC bzw. ulimit -u für den Service-User) und neue Prozesse lassen sich nicht mehr starten. CPU und RAM haben meist noch Reserven, aber die Appliance reagiert nicht mehr. SEPPmail nennt das in den Revision Notes einen system freeze. [2]
Was 15.0.4.1 ändert
Mit 15.0.4.1 ergänzt SEPPmail den fehlenden waitpid()-Aufruf. Beendete Kindprozesse werden wieder abgeräumt, ihre PIDs werden freigegeben. Der Fix ist in den Release Notes unter der internen Referenz 60324 geführt. [1]
Wer ist betroffen?
Betroffen sind alle SEPPmail-Appliances mit Patch 15.0.4. Ältere Stände sind nicht betroffen, weil der Bug erst mit 15.0.4 eingeführt wurde. [1]
Wie schnell der Effekt eintritt, hängt vom Mail-Aufkommen ab. In Umgebungen mit hohem Mail-Volumen ist das Limit entsprechend früher erreicht, in kleineren Setups dauert es länger.
Empfehlung
Wer 15.0.4 produktiv betreibt, sollte 15.0.4.1 ohne Verzögerung einspielen.
Ist eine Appliance bereits eingefroren, schafft ein Reboot wieder Zugriff. Da der Bug im Patch selbst sitzt, baut sich der Effekt danach allerdings erneut auf. Ein Reboot ist also nur eine Notmaßnahme, die Zeit bis zum eigentlichen Hotfix verschafft.
Für Cluster-Setups beschreibt SEPPmail die Update-Reihenfolge in einem eigenen Doku-Abschnitt. [3] Im Regelfall ist die Reihenfolge zwischen gleichberechtigten Cluster-Partnern beliebig. Zu beachten sind zwei Ausnahmen: Cluster mit virtuellen IP-Adressen, bei denen die für den SMTP-Empfang konfigurierte Hierarchie greift und Frontend-/Backend-Cluster, in denen die Frontend-Maschinen ohne eigene Datenbank zuerst aktualisiert werden.
