phlyMail Support Board

[mso]

Gut, meine Annahme war nicht ganz korrekt. Nicht PHP 4 ist das Problem, sondern PHP 5 kleiner 5.2.0. phlyMail benötigt seit Version 3.7.0 PHP 5.2.0 oder neuer - siehe dazu hier. Das Kommandozeilen-PHP dürfte dann einfach älter sein.
Ein

Code: Select all

/pfad/zu/php -v

aiuf der Konsole gibt Aufschluss darüber.

[marac]

Stimmt... Die Kommandozeilenversion ist 5.0.3, während die Seiten im Browser über Version 5.2.5 geparst werden...
Werde jetzt mal sehen, dass ich das Hosterseitig korrigiert bekomme.
Danke erstmal...

[marac]

Sodala, mein CronJob ruft nun also auch ein PHP5.2.5, allerdings klappt der Background-Fetch trotzdem nicht...
Folgende Meldungen wirft der CronJob:

Warning: set_time_limit(): Cannot set time limit in safe mode in /pfad/zu/phlymail/backend/email.fetcher.php on line 17
Hmmm, die Kurzdiagnose im Config sagt allerdings: Safe Mode: Off
Allerdings steht in der PHPInfo GlobalValue: On, LocalValue: Off - Kann es sein, dass beim Aufruf per Shellscript nicht der LocalValue greift, der beim Abruf der Seiten über den Webserver gilt?
Spielt das überhaupt eine Rolle, oder ist dann nur das Risiko eines TimeOut höher, sollte aber grundsätzlich trotzdem funktionieren?

Warning: parse_ini_file(choices.ini.php): failed to open stream: No such file or directory in /pfad/zu/phlymail/backend/email.fetcher.php on line 18
Das sieht mir etwas gravierender aus, kann das damit zusammenhängen, dass ich die shared/config in einem anderen Pfad habe? Dürfte ja eigentlich nicht, denn die choices.ini.php liegt doch direkt im "normalen" phlymail-Verzeichnis...

Noch eine Frage am Rande: Greift beim Backend-Fetcher nicht die Einstellung für die Fehlerberichterstattung? Denn dann müssten Warnings doch eigentlich ausgeblendet werden...

[mso]

Allerdings steht in der PHPInfo GlobalValue: On, LocalValue: Off - Kann es sein, dass beim Aufruf per Shellscript nicht der LocalValue greift, der beim Abruf der Seiten über den Webserver gilt?

Vermutlich greift in Ihrer speziellen Konfiguration beim Aufruf des CLI-PHPs eine andere php.ini als beim Aufruf über den Webserver. Ein Vergleich der phpinfo() aus der Kurzdiagnose der Config mit der Ausgabe von php -i auf der Konsole (am besten mit der Shell, unter der der Cron rennt) sollte Aufklärung bringen.

Das sieht mir etwas gravierender aus, kann das damit zusammenhängen, dass ich die shared/config in einem anderen Pfad habe? Dürfte ja eigentlich nicht, denn die choices.ini.php liegt doch direkt im "normalen" phlymail-Verzeichnis...

Ich schätze, dies hängt mit dem obigen Problem direkt zusammen. Unter Cron greift wohl der SafeMode, was denn das Einlesen der choices.ini.php verhindert. Vielleicht hilft es ja schon, das Abholen in die Crontab des WWW-Users zu packen, also in die des Users, unter dem der Apache läuft.

Noch eine Frage am Rande: Greift beim Backend-Fetcher nicht die Einstellung für die Fehlerberichterstattung? Denn dann müssten Warnings doch eigentlich ausgeblendet werden...

Da die choices.ini.php nicht eingelesen werden kann, schlägt auch das Einlesen der entsprechenden Einstellung fehl.

[Armigo]

Hallo alle zusammen,

ich habe phlymail 3.07.11 Lite auf meinem Strato PowerPlus L Webpaket installiert und auch eingerichtet. Läuft soweit alles gut, bis auf das Abholen der Mails bei GMX... Nun wollte ich besagten CronJob bei Strato einrichten, aber es tut sich nichts bei mir. Folgenden Befehl habe ich bei den Einstellungen unter "Cronjobs" in der Befehlszeile eingetragen:

cd /phlymail/backend/ /bin/php -f /phlymail/backend/email.fetcher.php

Für die Widerholung bietet Strato eine eigene Maske an, sodass ich die Sternchen weggelassen habe. Aber auch mit Sternchen passiert nichts.

Ich weiss leider auch nicht, wie man diese Fehlermeldungen auslesen kann. Bin absolut unerfahren, was diese Dinge angeht.

Vielen Dank schonmal und viele Grüße
Armin

[Armigo]

Hier nochmal ein kleines Update zu meinem Problem:

Bei Strato kann man sich eine E-Mail zukommen lassen, wenn ein CronJob ausgeführt wurde. In dieser E-Mail steht bei jeder Ausführung folgendes drin:

/bin/sh: /phlymail/backend: does not exist

In den FAQ von Strato steht drin, dass man die Pfadangaben relativ zum Stammverzeichnis angeben soll. Der "phlymail" - Ordner liegt allerdings direkt im Stammverzeichnis. Deshalb kann ich mir die Fehlermeldung nicht erklären.

Hat jemand ähnliche Probleme bei Strato bzw. wo liegt mein Fehler genau?

Vielen Dank und herzliche Grüße
Armin

[mso]

Ein Pfad der Form /phlymail/backend/ ist "absolut", also ausgehend vom obersten Verzeichnis der Festplatte des Servers. In Ihrem Falle sollte da wohl eher sowas stehen:

Code: Select all

cd backend/ && /bin/php -f email.fetcher.php

[Armigo]

Hallo und vielen Dank für den Tipp!

Mit dem Befehl

Code: Select all

cd backend/ && /bin/php -f email.fetcher.php

...habe ich nach Ausführung des CronJobs folgende Mail erhalten:

/bin/sh: backend/: does not exist

Ich habe es dann mit folgendem Befehl ausprobiert:

Code: Select all

cd ./phlymail/backend/ && /bin/php -f email.fetcher.php

...mit dem Resultat, dass ich nun jedesmal eine leere E-Mail erhalte. Geändert hat sich aber sonst nichts. Den Pfad müsste er also jetzt gefunden haben, aber wieso werden die Mails dann nicht abgeholt?

Hier mal der Link zur FAQ von Strato, falls ich etwas übersehen haben sollte: http://www.strato-faq.de/view.php4?articleid=1465&extern=1

Vielen Dank
Armin

[Armigo]

Ich habe es noch geschafft, per SSH auf den Server zugreifen zu können. Wenn ich den Befehl per SSH direkt ausführen lasse, dann wird auch dort kein Fehler angezeigt. Die PHP-Version auf dem Server ist 5.2.9. "display_errors" ist ebenfalls auf "On" gestellt. Ich habe dies mit

Code: Select all

/bin/php -i | grep display_errors

...überprüft. Ich hoffe, dass hat weitergeholfen... mir leider nicht

[mso]

Ist in den Konten eingestellt, dass die Mails auch per Hintergrundprozess geholt werden sollen? In den Konten müsste dazu im entsprechenden Feld ein Wert >0 stehen. Wenn parallel zu Ihren Versuchen acuh das Frontend von phlyMail läuft (Sie also eingeloggt sind) und dort regelmäßig Mails geholt werden, kann es sein, dass die o.a. Zeit noch nicht wieder erreicht ist. Wenn z.B. per Hintergrundprozess alle 20 min Mails geholt werden sollen, das letzte Abholen im Frontend aber weniger als 20min her ist, tut der CronJob-Prozess nichts.

[Armigo]

Das war der entscheidende Hinweis! Vielen Dank dafür! Jetzt funktioniert es einwandfrei. Vielen Dank nochmals für die Hilfe!!!

[jm-edv]

Wie arbeitet das Skript denn genau beim erneuten Aufruf bzw. nach Ende der Skriptlaufzeit?!
Ich habe in der Installation insgesamt 83 Profile - die Mails werden im Hintergrund (falls eingeloggt) alle 10 Minuten abgerufen und der CronJob läuft alle 15 Minuten. Jetzt habe ich den Eindruck (wenn ich nach der Login-Angabe in der profiles Tabelle gehe), dass nie alle Profile abgerufen werden. Der Abruf beginnt mit den ersten - irgendwann ist die Skriptlaufzeit erreicht und es wird abgebrochen - nach 15 Minuten wird wieder mit dem ersten angefangen und nach Ende der Skriptlaufzeit wieder irgendwo abgebrochen?!

[mso]

"Scriptlaufzeit" gibt es ja nicht auf der Konsole.

Ich werde ja nicht müde, zu betonen, dass unsere Cronjob-Scripts NICHT per cronjob.de oder andere, echte Cronjobs simulierende Dienste aufgerufen werden sollen. Das, was Sie beschreiben klingt jedenfalls sehr danach.

Im Endeffekt ist der Aufruf der Cronjob-Scripts über den Browser die Kombination aller denkbaren Nachteile bei der Scriptausführung: Es gibt eine strenge Limitierung hinsichtlich der Laufzeit, die Einfluss- und Ausgabemöglichkeiten sind begrenzt und ein Abbruch der HTTP-Verbindung beendet das Script vorzeitig.

Es gibt zwei Dinge, die Sie tun können:
- Upgrade auf einen Webspace / Server, wo CronJobs möglich sind
- Kürzeres Aufrufintervall des CronJobs
- Abholfrequenz der Konten reduzieren, auf z.B. alle 20 Minuten

[jm-edv]

Vielleicht habe ich mich etwas falsch ausgedrückt oder nicht alles vollständig beschrieben.
Der Cronjob wurde über das Web-Paket eingerichtet - nicht über einen 'externen Anbieter'. Führe ich den CronJob über eine SSH-Konsole aus, ist das Verhalten identisch mit dem automatisch eingerichteten CronJob über das Backend des Hosters. Irgendeine Ausgabe oder Fehlermeldung erfolgt bei beiden Verfahren nicht - ich denke mal das ist richtig?!
Das nicht alle Profile bearbeitet werden, kann doch eigentlich nur daran liegen, dass das Skript irgendwann stoppt/abbricht, oder?! Die Abholfrequenz werde ich auf jeden Fall einmal reduzieren.

[mso]

Meine "Diagnose" bezog sich natürlich ganz auf das, was ich aus Ihren Infos ziehen konnte. Und symptomatisch klang das schon sehr nach HTTP-Aufruf. Dem ist also doch nicht so.

Natürlich kommt genauso ein Absturz mit einem bestimmten Profil in Betracht. Naheliegend wäre ein Problem mit TLS / SSL. Die entsprechenden Bibliotheken sind verhältnismäßig kompliziert einzubinden und verzeihen Fehler sehr selten.
Bis jetzt ist dies aber reine Spekulation. Können Sie zeitweise die Fehlerberichterstattung von phlyMail aktivieren und dann das Script direkt auf der Konsole Aufrufen? Achten Sie dabei auf die Laufzeit und evtl. auftretende Fehlermeldungen. Lassen Sie ansonsten Ihre PHP-Instanz vom Hoster auf ein höheres Error-Logging-Level stellen und nach dem erneuten Durchlauf sich mal das entsprechende Fehlerlog zukommen. Ergibt das genauere Erkenntnisse?