PHP8.4.24 + b1gmailServer 2.8.3306 - Warteschleifeneinträge

Es könnte an der PHP Version liegen aber eher weniger an dem BMS da es beim Update nur um die Authentifizierung ging und nicht um die zustellung.

Ich schaue mir das morgen an...

Meine technische Einschätzung:

"Timeout while connecting socket" kommt vom b1gMailServer-Queue-Dienst beim Aufbau der ausgehenden TCP-Verbindung zum Ziel-MX/Relay, nicht von PHP oder pipe.php. Die PHP-Version steuert die SMTP-Verbindung nach aussen nicht.

Unsere bisherigen Änderungen an Auth/pipe.php würden eher Fehler im Bereich Pipe/Inbound verursachen, nicht diesen Connect-Timeout.

Eine stark wachsende Queue kann entstehen durch:

• Zielserver, die Verbindungsversuche einfach „droppen“
• mehrere MX-/A-Records × 60 s Timeout pro Versuch
• blockierte Worker durch hängende Outbound-Verbindungen

Ich würde testweise ein betroffenes Ziel direkt vom Server prüfen:

dig +short MX beispiel.ch
nc -vz -w 5 mx1.beispiel.ch 25
time nc -vz -w 65 <IP> 25

Sind immer dieselben Domains/IPs betroffen und dauert der Connect tatsächlich ~60 Sekunden?

Rein der Wechsel PHP 7.4 > 8.4 sollte diesen TCP-Connect-Timeout normalerweise nicht verursachen.

Zitat von ManDal

Meine technische Einschätzung:

"Timeout while connecting socket" kommt vom b1gMailServer-Queue-Dienst beim Aufbau der ausgehenden TCP-Verbindung zum Ziel-MX/Relay, nicht von PHP oder pipe.php. Die PHP-Version steuert die SMTP-Verbindung nach aussen nicht.

Unsere bisherigen Änderungen an Auth/pipe.php würden eher Fehler im Bereich Pipe/Inbound verursachen, nicht diesen Connect-Timeout.

Eine stark wachsende Queue kann entstehen durch:

• Zielserver, die Verbindungsversuche einfach „droppen“
• mehrere MX-/A-Records × 60 s Timeout pro Versuch
• blockierte Worker durch hängende Outbound-Verbindungen

Ich würde testweise ein betroffenes Ziel direkt vom Server prüfen:

Code

dig +short MX beispiel.ch
nc -vz -w 5 mx1.beispiel.ch 25
time nc -vz -w 65 <IP> 25

Sind immer dieselben Domains/IPs betroffen und dauert der Connect tatsächlich ~60 Sekunden?

Rein der Wechsel PHP 7.4 > 8.4 sollte diesen TCP-Connect-Timeout normalerweise nicht verursachen.

Alles anzeigen

Hi Netzwerkebene passt alles bei Claus, ich vermute das es etwas mit PHP zu tun hat, da PHP 8 ja strikter agiert als php 7 und damit ggf, einiges an verbindungen oder TLS anders anfasst. Oder im B1GMailServer selber ist im Zusammenhang mit php 8 etwas anders, was noch angepasst werden muss.

Claus sein System wurde komplett auf die neue Debian Trixie umgstellt, also nicht nur PHP. Aber Systemseitig ist alles getestet. Ich habe zum Test PHP7 parallel getestet, damit geht es. Nur PHP 8 nicht. Daher ein Zusammenhang B1GMSzu PHP8.

Zitat von informant

Hi Netzwerkebene passt alles bei Claus, ich vermute das es etwas mit PHP zu tun hat, da PHP 8 ja strikter agiert als php 7 und damit ggf, einiges an verbindungen oder TLS anders anfasst. Oder im B1GMailServer selber ist im Zusammenhang mit php 8 etwas anders, was noch angepasst werden muss.

Claus sein System wurde komplett auf die neue Debian Trixie umgstellt, also nicht nur PHP. Aber Systemseitig ist alles getestet. Ich habe zum Test PHP7 parallel getestet, damit geht es. Nur PHP 8 nicht. Daher ein Zusammenhang B1GMSzu PHP8.

danke für den Paralleltest

"Timeout while connecting socket" entsteht beim BMS-Outbound-Connect (queue_timeout), nicht in PHP.

PHP (pipe.php) wird nur für Inbound genutzt.

Ein Zusammenhang mit PHP 8 ist trotzdem denkbar, eher indirekt: Inbound und Outbound teilen sich den Thread-Pool. Unter hoher Last könnte eine langsamere oder problematischere Pipe unter PHP 8 Worker länger belegen und Outbound dadurch aufstauen. Auf kleineren Systemen fällt so etwas oft kaum auf.

Zum Eingrenzen wäre hilfreich, bei sonst gleicher Config nur php_path zu vergleichen:

printf 'From: test@example.com\nTo: user@domain.ch\nSubject: t\n\nx\n' \
  | "$PHP" /pfad/zu/b1gmail/interface/pipe.php --timeout=60 -- "user@domain.ch"; echo exit=$?

time "$PHP" .../pipe.php --timeout=60 -- "user@domain.de" < /tmp/test.eml

In der Queue Socket-Timeouts (Zielhosts?) und Pipe-/Inbound-Fehler getrennt betrachten, treten letztere vor allem unter PHP 8 auf?

Also klinke mich hier auch nochmal kurz ein!

wenn ich im Admin Panel /usr/bin/php7.4 nehme als php pfad habe ich gefühlt 99% weniger hängende bzw bereits ausgelieferte Mails die in der warteschleife hängen bleiben! dort hilft mir dann auch nur ein leeren der Warteschleife von hand!

Die propleme fangen meiner einschätzung nach ab Php8.0 an! wobei es da bis php8.5 auch unterschiede gibt! php8.0-php8.4 machen meiner meinug nach mehr probleme als php8.5

Ich kann mich hier allerdings nur auf test ergebnisse berufen!

ich habe jede php version knapp 2 stunden getestet und habe mit verschiedenen mails meinen mailserver versorgt!

unterm strich war /usr/bin/php7.4 dabei die stabilste version ohne ständig die warteschleife leeren zu müssen!

Somit kann ich ManDal hier zustimmen! ich denke auch das es an php liegt und nicht an b1gmailserver direkt. Ich hatte am anfang auch die vermutung das es am server liegt! da es aber unterschiede in den php versionen gibt tendiere ich nun auch zu php als verursacher

Zitat von Loadbox

Also klinke mich hier auch nochmal kurz ein!

wenn ich im Admin Panel /usr/bin/php7.4 nehme als php pfad habe ich gefühlt 99% weniger hängende bzw bereits ausgelieferte Mails die in der warteschleife hängen bleiben! dort hilft mir dann auch nur ein leeren der Warteschleife von hand!

Die propleme fangen meiner einschätzung nach ab Php8.0 an! wobei es da bis php8.5 auch unterschiede gibt! php8.0-php8.4 machen meiner meinug nach mehr probleme als php8.5

Ich kann mich hier allerdings nur auf test ergebnisse berufen!

ich habe jede php version knapp 2 stunden getestet und habe mit verschiedenen mails meinen mailserver versorgt!

unterm strich war /usr/bin/php7.4 dabei die stabilste version ohne ständig die warteschleife leeren zu müssen!

Somit kann ich ManDal hier zustimmen! ich denke auch das es an php liegt und nicht an b1gmailserver direkt. Ich hatte am anfang auch die vermutung das es am server liegt! da es aber unterschiede in den php versionen gibt tendiere ich nun auch zu php als verursacher

Alles anzeigen

Danke für die ausführlichen Tests mit den PHP-Versionen. Das passt zu unseren Beobachtungen.

Das Problem scheint nicht direkt am BMS-Outbound zu liegen, sondern an der DNSBL-Prüfung von b1gMail über pipe.php. Bei vielen DNSBL-Einträgen und einzelnen Timeouts kann die Verarbeitung unter PHP 8 auf über 30 Sekunden pro Mail steigen.

Unsere Empfehlung bei b1gMailServer:

• DNSBL unter b1gMail > E-Mail > Anti-Spam deaktivieren und stattdessen direkt in BMS als Zonen pflegen, z. B. zen.spamhaus.org oder bl.spamcop.net.
• Danach php_path wieder auf PHP 8 setzen und die Queue beobachten.
• Bei uns lief pipe.php danach unter PHP 8 wieder mit ca. 0,1 statt über 30 Sekunden.

Also ich hab alle einträge unter DNSBL mal gelöscht! das ganze neu gestartet!

unter php8.1 hatte ich dann plötzlich 8 oder mehr PHP8.1 timeouts in Webmin!

habe dann wieder zurück auf PHP7.4 um,gestellt und die Timeouts waren alle weg!

Das ganze mit leerer DNSBL

Danke für den Hinweis, dann kann ich weiterschauen.

SLM  informant bevor wir weiter spekulieren: Wie sieht es bei euch unter temp/session/ aus?

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

Die Frage

bevor wir weiter spekulieren: Wie sieht es bei euch unter temp/session/ aus?

kommt daher, das ich ebenfalls die Probleme mit den Warteschleifen einträge hatte! und die nicht gelöscht wurden automatisch!

wie sich herraus gestellt hat hatte ich 1,5 Millionen einträge in der /temp/session/ ( laufzeit seit knapp 10 jahre ) ,seit dem die weg sind macht auch der Warteschleifen Dienst keine zicken mehr!

fragt bitte nicht warum da so viele files drin waren bei seesion, kann mir das auch nicht erklären! fakt war aber das sich die temps nicht gelöscht haben

Ja, ich werde in der 7.5.0 noch einen Fix einbauen, damit sich solche Mengen an Session-Dateien möglichst gar nicht erst ansammeln und die Bereinigung zuverlässiger funktioniert.

Die rund 1,5 Millionen Dateien bei Loadbox waren so viele, dass das direkte Löschen schlicht zu lange gedauert hat. Deshalb habe ich den Session-Ordner verschoben und direkt neu angelegt:

mv temp/session temp/session_old
mkdir temp/session
chmod --reference=temp/session_old temp/session
chown --reference=temp/session_old temp/session

Danach konnte der alte Ordner separat gelöscht werden:

rm -rf temp/session_old

Zitat von Sebijk

Das Problem mit den Sessions kenne ich. Ich hatte da ein Skript am laufen, dass diese Einträge in dem Session-Ordner monatlich löscht. Mittlerweile hab ich den Ordner nur noch als tmpfs eingebunden, so dass es spätestens mit dem Restart leer ist.

das die sessions gecleant werden stellt man in der php ini ein^^ sonst schmeißt du ja alle einfach raus

cleaning alle 1000 aufrufe sollte man machen. das ist ideal.

########################################################################

Mit deinen Einstellungen (gc_probability = 1 und gc_divisor = 1000) hat jeder 1.000ste Seitenaufruf (0,1 % Chance) das Recht, den Ordner komplett nach abgelaufenen Sessions zu durchsuchen und diese zu löschen.

Wie viele Dateien letztendlich im Ordner liegen bleiben, bestimmen zwei Faktoren:

1. Die Lebensdauer der Sessions (session.gc_maxlifetime)

Standardmäßig löscht PHP nur Sessions, die älter als 1440 Sekunden (24 Minuten) sind.

• Alle Dateien von Benutzern, die innerhalb der letzten 24 Minuten auf deiner Website waren, bleiben garantiert liegen.
• Nur die Dateien von Benutzern, die länger als 24 Minuten inaktiv sind, werden beim nächsten GC-Durchlauf gelöscht.

2. Dein Besucheraufkommen (Traffic)

• Wenig Traffic: Wenn deine Website nur alle paar Stunden aufgerufen wird, triggert der Garbage Collector selten. Es kann sein, dass der Ordner zeitweise auf ein paar tausend Dateien anwächst, bevor der nächste "Putzdienst" anspringt.
• Hoher Traffic: Bei konstant vielen Besuchern wird die 0,1 %-Chance sehr oft getroffen. Der Ordner wird quasi durchgehend sauber gehalten. Es liegen dann fast nur noch die Sessions der aktuell aktiven Nutzer im Ordner.

Fazit

Wenn deine Website nicht gerade zehntausende aktive Nutzer gleichzeitig hat, werden weit weniger als 35.000 Dateien im Ordner liegen bleiben. Bei normalen Websites sinkt die Zahl meist auf ein paar Hundert bis wenige Tausend aktive Sessions.

Möchtest du den Befehl wissen, mit dem du die genaue Anzahl der aktuell angesammelten Session-Dateien im Ordner auslesen kannst, um den Vorher-Nachher-Vergleich zu sehen?

Hinweis. Dieser Text wurde aus meiner Dokumentation durch eine KI aufgearbeitet, damit er für Euch leichter verständlich ist!