PHP8.4.24 + b1gmailServer 2.8.3306 - Warteschleifeneinträge

  • Ja und nein. Grundsätzlich sollte PHP die abgelaufenen Sessions selbst bereinigen, sofern die entsprechenden Einstellungen korrekt gesetzt sind. Ich hatte aber schon mehrfach Systeme, bei denen der Session-Ordner trotzdem über längere Zeit nicht oder nicht zuverlässig bereinigt wurde.

    Genau für solche Fälle halte ich eine zusätzliche, definierte Bereinigung für sinnvoll. Alles, was älter als X Tage ist, kann dabei gezielt entfernt werden. Damit ist man nicht davon abhängig, ob und wann der PHP Garbage Collector tatsächlich greift.

    Neu gibt es in b1gMail 7.5.0 die "Geplanten Aufgaben". Das ist der ehemalige CleverCron, den ich fest in den b1gMail Core integriert habe. Darüber lässt sich auch die Session-Bereinigung sauber und regelmässig ausführen.

    Die 7 Tage aus meinem Beispiel sind für Sessions wahrscheinlich etwas sportlich gewählt. Das ist aber komplett frei konfigurierbar. Man könnte die Bereinigung beispielsweise einmal pro Woche um 04:00 Uhr laufen lassen und nur Session-Dateien entfernen, die älter als 30 Tage sind.

    Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.


    Damit ersetzt b1gMail die PHP-eigene Session-Bereinigung nicht, sondern hat zusätzlich einen kontrollierten Fallback. Selbst wenn der PHP-GC aus irgendeinem Grund nicht sauber arbeitet, wächst der Session-Ordner dann nicht wieder über Monate oder Jahre auf hunderttausende oder sogar Millionen Dateien an.

    • Offizieller Beitrag

    Bitte den Text eindeutig als KI-generiert bezeichnen.

  • Bitte den Text eindeutig als KI-generiert bezeichnen.

    Den Text hab ich aus meiner Doku so generieren lassen, wir sind doch intern oder ist der Thread extern lesbar? Weil die Daten sind aus meiner Doku nur aufgearbeitet durch KI bzgl. struktureller Ansicht. Sofern der Thread öffentlich ist, dann werd ich das zukünftig kennzeichnen, intern braucht man das nicht, wenn es keine reine KI Ausgabe ist. Satz für KI Aufarbeitung ist als Hinweistext hinzugefgt worden!

  • Ich hatte das seit Umstellung auf PHP 8.3, allerdings liefere ich jetzt endlich über Postfix aus, ist viel bequemer und besser als über b1gmail selbst auszuliefern, da bleibt gar nichts mehr hängen und Signieren, Vieren und Spamprüfung ist direkt viel besser und vor allem immer up2date danke updates

  • ls /pfad/zu/b1gmail/temp/session/ | wc -l

    42917

    find /pfad/zu/b1gmail/temp/session/ -type f -size 0 | wc -l

    39220

    -> Das ändert sich natürlich laufend.

    Ich verstehe nicht wie man Sessions überhaupt in Datei speichern kann, lager das doch auf Reddis oder Memcached aus. Ich hab das jetzt seit fast 11 Jahren alles in memcached und ich hatte seither nie wieder irgendein Problem, geht so schnell und alles top damit mit 40K logins am Tag, keine io Probleme, blitzschnell

  • Ich hatte das seit Umstellung auf PHP 8.3, allerdings liefere ich jetzt endlich über Postfix aus, ist viel bequemer und besser als über b1gmail selbst auszuliefern, da bleibt gar nichts mehr hängen und Signieren, Vieren und Spamprüfung ist direkt viel besser und vor allem immer up2date danke updates

    Cool. Wie machst du das mit der Kundenverwaltung von IMAP/POP3/SMTP? Das läuft doch nur über den BMS?

  • Ich verstehe nicht wie man Sessions überhaupt in Datei speichern kann, lager das doch auf Reddis oder Memcached aus. Ich hab das jetzt seit fast 11 Jahren alles in memcached und ich hatte seither nie wieder irgendein Problem, geht so schnell und alles top damit mit 40K logins am Tag, keine io Probleme, blitzschnell

    Memcached oder Redis kann für Sessions durchaus sinnvoll sein, gerade bei mehreren Webservern oder entsprechend hoher Last.

    Ich sehe bei 40K Logins pro Tag aber ehrlich gesagt noch keinen zwingenden Grund, deshalb von File-Sessions wegzugehen. Bei vernünftigem lokalen Storage, insbesondere SSD/NVMe, sollte das erst einmal kein nennenswertes I/O- oder Performanceproblem darstellen.

    Wenn File-Sessions nachweislich zum Flaschenhals werden, kann man über Redis oder Memcached sprechen. Solange sie aber problemlos funktionieren, würde ich nicht zusätzliche Infrastruktur einführen, nur um ein Problem zu lösen, das in der Praxis gar nicht vorhanden ist.

  • Ich hatte das seit Umstellung auf PHP 8.3, allerdings liefere ich jetzt endlich über Postfix aus, ist viel bequemer und besser als über b1gmail selbst auszuliefern, da bleibt gar nichts mehr hängen und Signieren, Vieren und Spamprüfung ist direkt viel besser und vor allem immer up2date danke updates

    Postfix als MTA ist natürlich eine saubere Lösung. Ich sehe dabei für ein klassisches b1gMail-Setup aber einen kleinen Haken:

    Sobald ich neben dem Webmail auch IMAP/POP3 anbieten möchte, brauche ich den b1gMailServer weiterhin. Dann betreibe ich am Ende Postfix und b1gMailServer parallel und verteile die Aufgaben auf zwei Systeme.

    Das kann man durchaus so bauen, aber für mich erhöht es erst einmal die Komplexität. Wenn die b1gMail-Queue zuverlässig funktioniert, sehe ich bei meinem Setup mit durchschnittlich 4-5K Mails pro Tag aktuell keinen wirklichen Vorteil darin.

    Interessant wäre aber, wie du das bei dir gelöst hast. Läuft der b1gMailServer weiterhin für IMAP/POP3 und Postfix übernimmt nur SMTP beziehungsweise die eigentliche Zustellung?


    Kleiner Nachtrag dazu:

    Was müsste dem b1gMailServer aus eurer Sicht noch beigebracht oder verbessert werden, damit ihr ihn wieder vollständig für die Mailverarbeitung einsetzen würdet?

    Mich würde vor allem interessieren, welche konkrete Funktion euch aktuell fehlt oder wo ihr technisch einen Nachteil gegenüber Postfix seht. Wenn es konkrete Punkte gibt, könnte man sich diese für eine kommende Version durchaus einmal genauer ansehen.

  • Ich denke der vorteil von Postfix ist die konfigurierbarkeit! sei es über Webmin oder über SSH.

    du kanst viel über die configs machen! diese möglichkeiten fehlern bei B1gmailserver in grossen teilen!

    nur um ein paar beispiele zu machen!

    opendkim

    opendmarc etc etc

    bei b1gmail joa lösen wir das über milter einträge.

    bei postfix machste das halt alles über die conf.


    was pop3/imap angeht! das läuft doch mit postfix über courier oder bin ich da grad komplett falsch?

  • Versteh mich nicht falsch, Postfix ist ein gutes Ding. Gerade die Konfigurierbarkeit über Config-Files und die damit verbundene Nachvollziehbarkeit und Flexibilität sind klare Stärken. Da wird der b1gMailServer vermutlich nie hinkommen, muss er aus meiner Sicht aber auch nicht.

    Bei der Integration von Dritttools sehe ich durchaus noch Potenzial. Wenn es konkrete Dinge gibt, die heute nur umständlich über Milter oder externe Konstrukte möglich sind, kann man sich sicher überlegen, wie man solche Integrationen im b1gMailServer künftig sauberer und flexibler gestalten kann.

  • Courier kennt deine b1gMail-Postfächer nicht. POP3 und IMAP müssen über b1gMailServer laufen.
    Wenn man Postfix als MTA nutzt, sollte man unbedingt darauf achten, mit dem MySQL-Plugin o.ä. die Empfängervalidierung umzusetzen und nicht blind jede Mail zu akzeptieren. Sonst überlastet man sich früher oder später den Server und landet wegen des Backscatters auf jeder Blockliste, die man sich vorstellen kann.

  • Also ich habe mal getestet. Mit PHP 7.* klappt es, mit PHP8.2 auch, ab PHP8.4 nicht mehr. Ab hier wird strict genutzt. Im BMS code sind noch alte Codezeilen wo er sich aufhängt und die PHP PIPE Prozesse abbricht. Ich denke und vermute also, dass der Code noch auf PHP8.4 und höher strict angenpasst werden muss (BMS).

    Nach etwas nachdenken ist mir eine Idee gekommen. Auf dem einzelnen MAIL SRV liegen ja noch alte PHP Dateien, die habe ich mal mit dne neuen überschrieben, siehe da, es funzt wieder ;)

    Einmal editiert, zuletzt von informant (18. September 2026 um 21:36)

  • Also ich habe mal getestet. Mit PHP 7.* klappt es, mit PHP8.2 auch, ab PHP8.4 nicht mehr. Ab hier wird strict genutzt. Im BMS code sind noch alte Codezeilen wo er sich aufhängt und die PHP PIPE Prozesse abbricht. Ich denke und vermute also, dass der Code noch auf PHP8.4 und höher strict angenpasst werden muss (BMS).

    Nach etwas nachdenken ist mir eine Idee gekommen. Auf dem einzelnen MAIL SRV liegen ja noch alte PHP Dateien, die habe ich mal mit dne neuen überschrieben, siehe da, es funzt wieder ;)

    Danke Manuel, daran habe ich auch nicht mehr gedacht.:thumbup:

    ManDal  Sebijk Prüft bitte mal die Anbindung des BMS, wenn man den BMS auf einem zweiten, eigenen Server laufen lässt - oder auf mehreren. Bislang muss man die /serverlib und /plugins - Ordner zusätzlich auf den zweiten Server kopieren. Manuel hat einen Weg gefunden, den /plugins Ordner zu mounten, das funktioniert scheinbar aber nicht mit dem /serverlib - Ordner. Man kann aber auch nicht ständig daran denken, alles zu synchronisieren.

    Hier gibt es auf alle Fälle großes Verbesserungspotential.

    Eine Bitte habe ich zusätzlich noch: Vergesst bitte nicht das Umlaut-Problem bei E-Mail-Ordnern & Apple Mail. Wenn es möglich wäre noch in einer BMS-Version die man noch unter b1gMail 7.4.x einsetzen kann.

    Vielen Dank an alle, die sich dem Thema angenommen haben. <3

  • Also ich habe mal getestet. Mit PHP 7.* klappt es, mit PHP8.2 auch, ab PHP8.4 nicht mehr. Ab hier wird strict genutzt. Im BMS code sind noch alte Codezeilen wo er sich aufhängt und die PHP PIPE Prozesse abbricht. Ich denke und vermute also, dass der Code noch auf PHP8.4 und höher strict angenpasst werden muss (BMS).

    Nach etwas nachdenken ist mir eine Idee gekommen. Auf dem einzelnen MAIL SRV liegen ja noch alte PHP Dateien, die habe ich mal mit dne neuen überschrieben, siehe da, es funzt wieder ;)

    Das hat meiner Einschätzung nach weniger mit einem strengeren Verhalten von PHP 8.4 zu tun, sondern eher damit, dass die Deprecated-Meldungen an dieser Stelle nicht sauber abgefangen werden.

    Soweit ich das aktuell sehe, erwartet der BMS bei der Keep-Alive-Pipe genau eine SMTP-Antwortzeile. Wird zusätzlich eine Deprecated-Meldung ausgegeben, kommen plötzlich mehrere Zeilen zurück. Damit konnte die Verarbeitung bisher nicht umgehen: Der BMS ist an der Stelle durcheinandergekommen bzw. hängengeblieben und hat den PHP-Pipe-Prozess anschliessend abgebrochen.

    Die Pipe-Verarbeitung im BMS habe ich deshalb robuster gemacht:

    • Lesen und Schreiben auf der Pipe laufen jetzt mit Timeout, der BMS bleibt dort nicht mehr endlos stehen.
    • Zeilen, die keine SMTP-Antwort sind (z. B. Deprecated:, Warning:, TypeError), werden übersprungen und ins Queue-Log geschrieben.
    • Ein Worker, der hängen bleibt, abstürzt oder unerwartete Ausgaben liefert, wird nicht wiederverwendet, sondern beendet.
    • Idle-Prozesse und Worker nach vielen Zustellungen werden zusätzlich recycelt, damit kein PHP-Prozess unbegrenzt weiterläuft.

    Wenn so etwas unter PHP 8.4 noch auftritt, sollte im Queue-Log jetzt etwas in dieser Richtung stehen:

    Inbound keep-alive pipe produced non-protocol output during RCPT TO: Deprecated: ...

    Die eigentlichen Deprecated-Stellen bleiben trotzdem ein Thema, vor allem in b1gMail (pipe.php / serverlib). Die härtere Pipe im BMS fängt die Auswirkungen ab; parallel schaue ich mir die betroffenen Stellen an, damit diese Meldungen gar nicht erst entstehen.

  • Eine Bitte habe ich zusätzlich noch: Vergesst bitte nicht das Umlaut-Problem bei E-Mail-Ordnern & Apple Mail. Wenn es möglich wäre noch in einer BMS-Version die man noch unter b1gMail 7.4.x einsetzen kann.

    Apple Mail übermittelt die Ordnernamen korrekt als Modified UTF-7 gemäss RFC 3501. Siehe dazu auch GitHub #24. Ein Ordner mit Umlaut kommt beispielsweise als „CREATE Umla&Awg-ut“ beim BMS an.

    Das eigentliche Problem lag im BMS. Die per IMAP empfangenen Ordnernamen wurden bisher nicht korrekt in den von der Datenbankverbindung verwendeten Zeichensatz latin1 konvertiert. Dadurch gingen Umlaute beim Erstellen von Ordnern über IMAP verloren. Ordner, die direkt über das Webmail angelegt wurden, waren davon nicht betroffen.

    Ich habe die Verarbeitung im BMS entsprechend angepasst. Eingehende Ordnernamen werden nun korrekt aus Modified UTF-7 dekodiert und passend zur latin1-Verbindung gespeichert. Bei LIST und STATUS erfolgt die Konvertierung wieder zurück nach Modified UTF-7, damit Clients wie Apple Mail die Ordnernamen korrekt erhalten.

    Ich werde die Änderung aber noch ausführlich mit verschiedenen IMAP-Operationen und Umlauten durchtesten, bevor ich sie freigebe.

  • ManDal  Sebijk Prüft bitte mal die Anbindung des BMS, wenn man den BMS auf einem zweiten, eigenen Server laufen lässt - oder auf mehreren. Bislang muss man die /serverlib und /plugins - Ordner zusätzlich auf den zweiten Server kopieren. Manuel hat einen Weg gefunden, den /plugins Ordner zu mounten, das funktioniert scheinbar aber nicht mit dem /serverlib - Ordner. Man kann aber auch nicht ständig daran denken, alles zu synchronisieren.

    Bisher kam selffolder (und damit der Pfad zu pipe.php / serverlib / PHP-Plugins) immer aus der Datenbank, also vom Webserver. Ein lokaler Eintrag in der b1gmailserver.cfg auf dem Mailserver wurde überschrieben. Deshalb musste man serverlib und plugins kopieren oder syncen – und ein reiner serverlib-Mount reicht nicht, weil pipe.php unter interface/ liegt und relativ ../serverlib plus die PHP-Plugins braucht.

    Das ist jetzt angepasst: Werte in /opt/b1gmailserver/b1gmailserver.cfg gelten auf diesem Host und überschreiben die DB.

    $Auf dem Mailserver reicht z. B.:

    Code
    selffolder      = /mnt/b1gmail/
    datafolder      = /mnt/b1gmail-data/
    php_path        = /usr/bin/php

    Gemountet werden sollte der komplette b1gMail-Web-Root (nicht nur serverlib):

    Code
    /mnt/b1gmail/
      interface/pipe.php
      serverlib/
      plugins/

    datafolder (Mailbestand) gehört auf ein gemeinsames NFS.

    Im Log steht dann etwas wie: Keeping local selffolder from b1gmailserver.cfg (not using DB value).

    Damit entfällt das ständige Synchronisieren der PHP-Ordner; jeder Mailhost zeigt einfach auf seinen lokalen Mount.

    Ein solches Setup (Web und Mail getrennt) habe ich hier selbst nicht zum Gegenprüfen. Ob der Mount in der Praxis so durchläuft – inkl. pipe.php, PHP-Plugins und datafolder – müsste noch an einer echten Split-Installation getestet werden. Rückmeldungen dazu wären sehr willkommen.

  • informant Das klingt doch interessant? Passt das zu meinem System?

  • PR: #27

    PHP-Prozesse wiederverwenden (inbound_reuse_process=1)
    Ab PHP 8.4 landen oft Deprecation-Meldungen auf stdout und stören das Pipe-Protokoll (RCPT/DATA). Der BMS hat sich dann in fgets festgefahren und den PHP-Prozess abgeschossen. Das ist auf BMS-Seite gehärtet (Timeouts, Rauschen ignorieren, kaputte Worker wegwerfen). Das Protokoll selbst bleibt gleich, PHP 7.4/8.2 sollen weiterlaufen. Die Deprecations in pipe.php/serverlib sind damit nicht weg, der BMS hängt sich nur nicht mehr daran auf.

    IMAP-Umlaute (Apple Mail)
    Ordnernamen gehen jetzt nach RFC 3501 als modified UTF-7 raus/rein. Speichern weiter passend zu SET NAMES latin1, auch wenn bm60_folders.titel utf8mb4 ist. Webmail-Ordner waren nie das Problem; nach dem Update in Apple Mail einmal die Ordnerliste neu laden.

    Zweiter Mail-Server
    Nur /serverlib oder nur /plugins zu mounten reicht nicht. Der BMS braucht den b1gMail-Webroot (interface/pipe.php, daneben serverlib/ und plugins/). In der b1gmailserver.cfg kann man das jetzt lokal überschreiben, ohne dass die DB-Werte für alles andere verloren gehen:

    Code
    selffolder = /mnt/b1gmail/
    datafolder = /mnt/b1gmail-data/
    php_path   = /usr/bin/php

    Den ganzen Baum mounten, nicht serverlib allein. Gehashte Beispiele stehen nach Install/Update in der cfg.

    Wichtig: So ein Split-Setup (Web und Mail getrennt) habe ich hier aktuell nicht zum Testen. Das ist also nur der Code-Weg, keine Bestätigung aus dem Betrieb. Wer das so fährt: bitte prüfen, ob pipe.php auf dem Mail-Host erreichbar ist und Zustellung/IMAP damit klappt. Feedback sehr willkommen.

    Zusätzlich: wenn logfile gesetzt ist, kann man mit logrotate=1 die Rotation vom BMS anlegen lassen (bei jedem Start, Pfad aus der cfg). Bestehende logfile=-Zeilen werden nicht nochmal angehängt.

    Kompatibel mit offiziellem b1gMail 7.4. Tester zu Keep-Alive (PHP 8.4), Apple Mail und vor allem Split-Server wären hilfreich.

  • Hast du die Apple-Mail-Sache getestet? Eine einfache Konvertierung nach latin1 (wie im PR) hatte bei mir nicht geholfen, da Apple Mail die Umlaute als zwei Zeichen z.B. "¨" (diaeresis) und "u" sendet. Man muss diese Paare erkennen und auf Umlaute zurück mappen, sonst erhält man bei Konvertierung sowas wie "?u" oder "u?", da "¨" nicht auf latin1 gemappt werden kann.

    Zu der Pipe-Sache: Ich würde das auf PHP-Seite fixen und nicht das Protokoll bzw. den Parser verkomplizieren. Reicht ein einfaches error_reporting(0) oder init_set-Deaktivierung von display_errors nicht aus?

  • Hast du die Apple-Mail-Sache getestet? Eine einfache Konvertierung nach latin1 (wie im PR) hatte bei mir nicht geholfen, da Apple Mail die Umlaute als zwei Zeichen z.B. "¨" (diaeresis) und "u" sendet. Man muss diese Paare erkennen und auf Umlaute zurück mappen, sonst erhält man bei Konvertierung sowas wie "?u" oder "u?", da "¨" nicht auf latin1 gemappt werden kann.

    Zu der Pipe-Sache: Ich würde das auf PHP-Seite fixen und nicht das Protokoll bzw. den Parser verkomplizieren. Reicht ein einfaches error_reporting(0) oder init_set-Deaktivierung von display_errors nicht aus?

    Bei meinen bisherigen Tests funktioniert die Darstellung der Umlaute auf dem iOS-Gerät grundsätzlich korrekt. Ordner, die in b1gMail mit Umlauten angelegt werden, erscheinen auf dem iOS-Gerät sauber mit dem richtigen Namen.

    Ich habe allerdings gerade festgestellt, dass es aktuell nur in diese Richtung funktioniert. Wird ein Ordner mit Umlauten direkt auf dem iOS-Gerät angelegt, wird der Name in b1gMail noch nicht korrekt übernommen.

    Da muss ich also nochmals ran, bevor der Fix vollständig ist.

    Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

    Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!