Versand steht still

[premium]

Die Änderung zeigt er an, das ist ja das komische...

[mirko]

wenn er aber weiter bei phpinfo() nicht den korrekten memory_limit Wert anzeigt, wirkt die Änderung nicht.

[premium]

Die Anzahl abzurufender Bounce-Mails ist bereits auf 1 gesetzt

Zu der php.ini: ich hatte hier vorher die phpinfo() aufgerufen und die unter \"Loaded Configuration File\" entsprechende php.ini bearbeitet..also müsste das eigentlich die richtige sein...

[mirko]

Unter Menü Einstellungen - Optionen die Anzahl abzurufender Bounce-Mails auf 1 setzen, dann sollte es eigentlich nicht zum Timeout kommen.

Das Ändern des Timeouts in der php.ini ist global für alle virtuellen Domains, pro Domain kann es aber auch noch einen php.ini mit abweichenden Einstellungen geben und dort wird wohl die 300 angegeben sein.

[premium]

Zwischenstand:

Hab zuerst den Cronjob deaktiviert und anschließend in der config.inc.php das error_reporting auf E_ALL gestellt. Ergebnis beim manuellen Ausführen war eine weiße Seite.

Dann habe ich das memory_limit in der php.ini auf 1024 MB hochgesetzt, Fehlermeldung beim manuellen Ausführen war nun diese:

Fatal error: Maximum execution time of 300 seconds exceeded in /srv/www/vhosts/apswm.de/httpdocs/inboxcheck.php on line 219 Script timeout at level 6.
Check options of email retrieving or for email sending.

Also bin ich nochmal in die php.ini gegangen und habe die maximum_execution_time auf 500 gesetzt. Lustigerweise hat das an der Fehlermeldung nichts geändert...ich frage mich wo nun die maximal 300 Sekunden herkommen? Die 500 wurden auf jeden Fall übernommen (Apache neustarten etc).

soviel zu dieser unendlichen Geschichte

[volkmar1]

Original von premium:
Edit: Hab grade mal das Memory Limit auf 256 MB hochgesetzt...das scheint noch nicht auszureichen (das Script bricht wieder ab), also werd ich das wohl erstmal so lassen müssen

ich habe das drin:

; Resource Limits ;
;;;;;;;;;;;;;;;;;;;

max_execution_time = 300 ; Maximum execution time of each script, in seconds
max_input_time = 180 ; Maximum amount of time each script may spend parsing request data
;max_input_nesting_level = 64 ; Maximum input variable nesting level
memory_limit = 1024M ; Maximum amount of memory a script may consume (128MB)

Gruß, Volkmar

[mirko]

Wenn Safemode off ist, dann sollte das mit dem Return-Path funktionieren.

Du kannst auch mal in der config.inc.php error_reporting(0); auf error_reporting(E_ALL); ändern. Man sollte jetzt vorübergehen den Aufruf des CronJob-Scripts deaktivieren und danach über Menü Einstellungen - Geplante Aufgaben das Script aufrufen. Man sollte dann sehen an welcher Stelle beim Abruf der Bounces der Fehler kommt.

[premium]

Nee nee, 1800 Empfänger hatte der Thread-Ersteller, ich hatte diesen Thread hier nur aufgegriffen, weil es das gleiche Problem ist und ich dafür keinen neuen eröffnen wollte. Wir haben in unserer Mailingliste deutlich mehr als 1800 Empfänger. Den Return-Path hatten wir schon auf ein extra Postfach eingestellt, die Antworten gehen an ein anderes nicht im SWM behandeltes. Der Safemode ist off, allerdings verschicken wir per php mail(). Geht das dann noch oder was sollte ich besser tun?

Edit: Hab grade mal das Memory Limit auf 256 MB hochgesetzt...das scheint noch nicht auszureichen (das Script bricht wieder ab), also werd ich das wohl erstmal so lassen müssen

[mirko]

Also bei 1800 Empfängern können wirklich keine 40.000 Bounce-Mails entstehen, das sind vielleicht auch größtenteils Spam-Mails, die sollten da nicht unbedingt drinliegen. Besser wäre ein Bounce-Postfach zu machen z.B. bounces@meine-domain.de und diese als Return-Path-Adresse definieren (bei PHP mit Safe Mode On und Versand per PHP mail(), funktioniert das nicht!). In das Postfach gehen dann nur reine Bounce-Mails. Von Zeit zu Zeit das Postfach wechseln, damit es nicht vollgespammt wird.

Wie groß die UIDL-Liste wird, weiss ich nicht, weil jeder Server unterschiedlich lange IDs/UIDL für jede E-Mail definiert. Habe gerade mal eine Mail auf meinem Server angeschaut, der hat ne UIDL von 20 Zeichen = 20 Byte gebildet. Bei 40.000 sind wir dann bei 800.000 Byte = 800 KB, dazu kommt dann noch die Größe der Mail in Byte. Das ganze hängt in einem PHP array(), gibt es natürlich einen Overhead.

[volkmar1]

Original von premium:
Ok, verstehe. Macht es als Workaround erstmal Sinn, das Memory Limit hochzusetzen? Wieviel Speicher braucht das Script wohl mit so einer langen UIDL-Liste?

Sinn macht das auf jeden Fall. Aber Du solltest erst mal prüfen, warum die ganzen Bouncemails entstehen, sonst wirst du das Problem nie los. Wie schon geschrieben, bei knapp 1800 Adressen sind das eindeutig zu viele.

[premium]

Ok, verstehe. Macht es als Workaround erstmal Sinn, das Memory Limit hochzusetzen? Wieviel Speicher braucht das Script wohl mit so einer langen UIDL-Liste?

[volkmar1]

Hm, ich frage mich gerade, wie bei einer Mailingliste mit läppischen 1740 Adressen 40000 Hardbounce-Mails entstehen können. So oft sendet das Skript ein Mail doch nicht raus.

Checke mal, indem Du in das Postfach mit den Bounces reinschaust, wer der Absender der Mails war. Es könnte sein, dass das die Bounce-Adresse war. Wenn Postfix als Mailserver läuft, kommt das vor.

BTW: Das Memory-Limit für php kann man auf einem rootserver problemlos hochsetzen. Habe ich bei mir auch gemacht, und der frisst so an die 200000 Adresse pro Mailingliste klaglos - inkl. funktionierendem Bouncemanagement.

[mirko]

Das Script selbst darf natürlich nicht 4 GB verwenden, sondern hat ein Speicherlimit (im phpinfo() memory_limit). Wenn das Limit überschritten ist, bricht das Script einfach ab. Bis jetzt geht das Abrufen der Bounces so:

* Abruf einer Liste von allen UIDLs (eindeutige IDs der E-Mails) aus dem Postfach, bei 40.000 Mails sind das richtige viele Bytes, die im Speicher gehalten werden müssen

* jetzt Liste der UIDLs durchgehen und die Mails einzeln holen und anschauen.


Ich denke, dass die Liste der UIDLs zu groß ist und damit kann er die Mails nicht mehr holen, weil der Speicher aufgebraucht ist. Genau aus diesem Grund ändere ich das ab der nächsten Version.

Wenn man in der config.inc.php error_reporting(0); auf error_reporting(E_ALL); ändert, dann wird im error_log des Servers wahrscheinlich ein Eintrag wegen des fehlenden Speichers auftauchen.


Nachtrag: Das schlimme an den Fehler, das Script wird einfach abgebrochen = aus dem Speicher geworfen, damit versucht er jedesmal wieder die Mails zu holen und damit passiert am Ende gar nichts mehr.

[premium]

Aber wie kann es denn sein, dass der Hauptspeicher zu wenig ist, wenn er grade mal z. B. 1 Bounce pro Postfach abrufen kann (und es sind nur 3 Postfächer angelegt). Zudem haben wir den SWM sogar auf einem Rootserver mit 4GB Speicher laufen...kann es wirklcih daran liegen? Es werden doch nicht alle E-Mails auf einmal abgerufen und dann nur eine bearbeitet oder?

[mirko]

Ich denke mittlerweile das Problem liegt am fehlenden Hauptspeicher und nicht an den E-Mails. Wenn zu viele im Postfach liegen reicht der Speicher für das Script nicht mehr aus und es wird abgebrochen. Ab der nächsten Version werden die E-Mails dann nach und nach abgeholt, damit es nicht zu Problemen mit fehlenden Hauptspeicher kommt, es dauert aber dann leider auch länger, weil er für jede Mail ins Postfach greifen muss.