phlyMail Support Board

[funstyler]

Hi, ich hab seid meinem neuen Server ein großes Problem.

Ich nutze phlyMail MessageCenter 4.02.00 auf einem selbst installierten Dedicated Root.

Normal soll der Client auch wenn ich nicht eingeloggt bin Mail abrufen... tut er nicht.

Dan n ruft er Sir ab wenn ich mich einlogge und bleibt dann aber ganz unterschiedlich bei profil 3 oder 4 hängen, bei näherer betrachtung meist bei 10 geholten mails, logge ich mich dann einmal aus und wieder ein mach er wieder 10 mails und stop wieder die arbeit. Das kann ich nun machen bis ich alle Profile habe. Also Login Daten usw sind korrekt.

Ich vermute ein Probem in der Server konfiguration, aber ich weiß leider überhaupt nicht wo ich suchen soll, in den Server logs ist alles ok, irgendwas in php vielleicht? Hat jemand ein Tip?

[mso]

Normal soll der Client auch wenn ich nicht eingeloggt bin Mail abrufen... tut er nicht.

Haben Sie denn den CronJob eingerichtet?

Ich vermute ein Probem in der Server konfiguration, aber ich weiß leider überhaupt nicht wo ich suchen soll, in den Server logs ist alles ok, irgendwas in php vielleicht? Hat jemand ein Tip?

Ein regelmäßiger Abbruch nach X Mails deutet fast auf eine Loginbremse beim Email-Provider hin. Was sind denn das für Mailkonten? Eigener Mailserver, der des Hosters oder Freemailer-Angebote?

[funstyler]

Nein es ist kein externer Email Provider dabei es sind alles local Postfächer.

Und das Problem besteht z.B. nicht wenn ich den Client einfach auf einen externen VServer lege den wir noch zur Verfügung haben. Komplett kopiert mit Mysql.

Also es muss schon was in der Server Config sein, nur ich weiß echt nicht mehr wo ich da noch suchen soll.

Cronjob hab ich noch nicht weil es Imap Konten sind. Oder geht das jetzt auch mit Imap Konten?

[mso]

Cronjob hab ich noch nicht weil es Imap Konten sind. Oder geht das jetzt auch mit Imap Konten?

Das geht schon einige Jahre mit IMAP-Konten, aber wie im Frontend auch derzeit "nur" mit der INBOX.

[funstyler]

OK ist drin, aber ein tip zum Server Problem haben Sie auch nicht oder?

[mso]

Meine Idee wäre jetzt, zu schauen, ob sich das Problem halbwegs löst. wenn Sie die Mails immer im Hintergrund abholen lassen. Sollte das keine Abhilfe schaffen, schauen wir genauer.

[funstyler]

Hi also das mit Cron Job hat geklappt, nun habe ich n8ur noch das Problem das der Filter (nicht Spam Filter) erst zieht wenn man auf das Postfach geht.

Kann mann dafür auch eine Cron Job anlegen?

Es ist so der PHLYMail die komplette Sortierung unserer Mail macht, und in die passenden Posteingänge verschiebt.

[mso]

also das mit Cron Job hat geklappt

Prima!

nun habe ich n8ur noch das Problem das der Filter (nicht Spam Filter) erst zieht wenn man auf das Postfach geht.

An sich macht das der Abholprozess, egal ob im Frontend oder via CronJob.

Wobei "erst auf den Posteingang gehen" ja leider eher dafür spricht, dass das Abholen auch via CronJob nicht so richtig klappt. Die Mailfilter greifen ja immer nur bei "frisch eingetroffenen" Mails, also solchen, die phlyMail noch nicht kennt.

Können Sie denn mal in der Config die Fehlerberichterstattung für Ihren User aktivieren? Gibt's denn dann eine irgendwie sichtbare Fehlermeldung beim Nachrichten abholen? Insbesondere dann, wenn der Abholprozess stehen bleibt?

[funstyler]

Ich glaube ich hab den Fehler gefunden.

Beim manuellen ausführen des Cron Befehls kam Fehler in PHP zum Vorschein.
Befehl

php -f email.fetcher.php

brachte das

PHP Deprecated: Directive 'register_long_arrays' is deprecated in PHP 5.3 and greater in Unknown on line 0
PHP Deprecated: Directive 'magic_quotes_gpc' is deprecated in PHP 5.3 and greater in Unknown on line 0
PHP Deprecated: Function set_magic_quotes_runtime() is deprecated in /home/vhost/********************/backend/email.fetcher.php on line 15

Habe das jetzt in der php.ini geändert, und werde morgen im laufenden Betrieb mal schauen ob Cheffe noch Probleme hat.

[jm-edv]

Mit dem CronJob habe ich mich noch nicht wieder beschäftigt - aber seit heute besteht auch bei mir das hier beschriebene Problem: Der Abruf von Mails stoppt mal nach 6, mal nach 24 und mal nach 63 Mails - also ganz unregelmäßig und nach dem Aktualisieren der Seite geht's wieder weiter. Da ich ein paar Konten neu eingebunden habe, sind es einige Mails mehr - gestern Abend bestand das Problem aber eigentlich noch nicht - dort wurden auch mehrere 100 Mails heruntergeladen.

In dem Error-Log konnte ich mehrmals die folgenden Einträge finden - 128MB MemoryLimit müssten aber doch eigentlich reichen?!
[06-Feb-2012 15:31:09] PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 35 bytes) in /*******/shared/lib/imap.inc.php on line 1201
[06-Feb-2012 15:31:04] PHP Notice: Undefined property: imap::$greeting in /*******/shared/lib/imap.inc.php on line 146

[mso]

In dem Error-Log konnte ich mehrmals die folgenden Einträge finden - 128MB MemoryLimit müssten aber doch eigentlich reichen?!

Sie lachen - aber abhängig von der Mailgröße kann das schon vorkommen. Das sind mehrere Faktoren:
- Mails und insbesondere deren Anhänge werden i.d.R. nicht binär übertragen, sondern in ASCII-kompatiblen Kodierungen, die leider die Größe um 25% (und mehr) aufblähen
- das Kommunikationsprotokoll (hier IMAP) ist leider auch recht "geschwätzig", wobei es an sich schon zu den kompakteren gehört
- vom erlaubten Speicher ist neben dem Bedarf für das PHP-Binary selbst und dem reinen Script auch aller Bedarf für Variablen usw. abzuziehen
- technisch bedingt kann der tatsächliche Speicherbedarf für z.B. 4MB Nutzdaten ein Mehrfaches sein
- offenbar ließ sich an der betroffenen Stelle der Code auch nicht dahingehend optimieren, dass nur der aktuell interessante Teil des Datenstroms im Speicher gehalten wird

Ein Memory-Limit-Problem lässt sich immer dadurch lösen, dass dem PHP-Prozess mehr Speicher eingeräumt wird. Das Limit bedeutet auch nicht, dass jeder Prozess dieses voll ausnutzt, im Gegenteil. Es wird nur soviel Speicher belegt, wie nötig ist.

Mit anderen Worten - das Hängenbleiben des Prozesses hat nichts mit der Zahl Mails zu tun, sondern es sind offenbar immer wieder welche dabei, deren Größe jenseits des für Email angemessenen ist. Leider sind die Alternativen zum Versand großer Anhänge nicht unbedingt so richtig endanwendertauglich (Upload auf Server im Netz, Versand des reinen Links).

[jm-edv]

Vielen Dank für die -wie immer- sehr ausführliche Antwort.
Ich habe das MemoryLimit nun nochmal verdoppelt und diesmal war bei 111Mails mit dem gleichen Fehler 'Ende'. Das Konto war vorher in Outlook eingebunden - da habe ich gerade einmal nachgesehen: insgesamt ca. 40 Mails zwischen 3 und 6 MB, ca. 20 Mails um 2MB und der Rest unter 1MB. Mich hat nur gewundert, dass gestern alle Konten problemlos synchronisiert wurden und dort waren auch ein paar größere Mails enthalten!?
D.h. also im Zweifel kann man hier nichts ändern sondern müsste wirklich nach einem Abbruch den Aufruf erneut anstossen?! Oder könnte man mit 'realpath_cache_size' (16K) bzw. 'realpath_cache_ttl' (120) ggf. noch etwas optimieren?!

[jm-edv]

Ich habe das Verhalten nochmal beobachtet und es ist insgesamt sehr seltsam. Bei einem User konnte ein Profil synchronisiert werden (Verbindung ohne SSL problemlos; Verbindung mit SSL hakte schonmal etwas und brachte auch zweimal den genannten Fehler), in dem etliche Mails zwischen 5 und 16 MB liegen. Ein anderes Profil (Verbindung mit SSL) hängt sich immer mal wieder auf -auch bei ganz kleinen Mails (1-4 KB)- und bringt die folgenden Fehler. Wird die Seite vollständig neu geladen geht's weiter und z.T. werden wesentlich mehr und größere Mails 'am Stück' verarbeitet. Ob einzelne Mails einfach irgendwie beschädigt sind?!

[06-Feb-2012 22:43:20] PHP Warning: Invalid argument supplied for foreach() in /*******/shared/lib/phm_streaming_mailparser.php on line 137
[06-Feb-2012 22:50:28] PHP Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 32 bytes) in /*******/shared/lib/imap.inc.php on line 1110

Diese Fehlermeldung kam einmal beim Abmelden:
Fatal error: Class 'mailparser' not found in /kunden/329584_45141/webseiten/asta/mail/handlers/email/fs.php on line 827

[mso]

Gut, also vermutlich wird das Problem dann eher nicht in zu großen Mails begründet sein. bis zu 10 MB würde ich als "normal" und akzeptabel heutzutage ansehen. Und die Sechs-MB-Mails werden auch nicht das Memory-Limit ausreizen.

Sie erwähnen SSL - und im Moment denke ich, dort sollten wir genauer hinschauen. Wie in einem anderen Thread erwähnt, ist SSL durchaus eine hakelige Angelegenheit. Wenn man da als Admin nicht aufpasst wie ein Schießhund, kommen am Ende die "lustigsten" Phänomene zustande. Ich habe nach der jetzigen Informationslage den Verdacht, dass bei Ihrer Installation da irgendwas klemmt, was PHP manchmal komplett aus dem Tritt bringt. Die von Ihnen im letzten Post zitierten zwei Fehlermeldungen haben im Übrigen nicht direkt miteinander zu tun. Das sehen Sie schon am Zeitstempel. Leider vermerkt das Logfile keine Prozess-Kennung, so dass die Zuordnung im Nachhinein nicht mehr so ohne Weiteres möglich ist.
Wie es ausschaut, kommt die Routine zum Einlesen der Mail auf IMAP-Ebene aus dem Tritt, gerät in eine Endlosschleife, schreibt dann den Speicher voll und wird schlussendlich vom Memory-Limit gestoppt.

Eskalieren Sie dieses Problem bitte parallel bei Ihrem Hoster. Vermutlich wird dieser einfach auf einen "Fehler in der Software" verweisen. Lassen Sie sich davon bitte nicht irritieren. Aus meiner Sicht ist ein Fehler in der SSL-Funktionalität vorhanden, der unter bestimmten Umständen zu Fehlern in PHP führt. Einziger Workaround bis zur Lösung des Problems wäre, von SSL auf unverschlüsselte Übertragung umzustellen. Mir ist klar, dass das nicht unbedingt eine Option für die Dauer ist.

[jm-edv]

Für heute muss ich sagen, dass bis jetzt alles problemlos funktioniert. Ich habe heute nochmal einige Konten/Profile (auch mit SSL) mit mehreren E-Mails unterschiedlicher Größe synchronisiert und alles lief reibungslos. Von den meisten Nutzern höre ich im Moment auch, dass es stabiler/schneller läuft als je zuvor. Ich habe im Moment wirklich keine konkrete Erklärung mehr Ich beobachte das Problem weiter und werde dann zunächst einmal den Hoster kontaktieren. Über die Ergbnisse werde ich hier natürlich wieder berichten.