Crons.php scheint nicht richtig zu laufen
Moderator: mirko
mit wget und http:// wirklich aufrufen lassen nicht mit php /var usw.., ich habe das selbst schon probiert, das gibt irgendwelche Rechte-Probleme, das Script bekommt seine Dateien nicht mehr auf und wird aus dem Speicher \"geschmissen\". In der Hilfe auch online http://www.supermailinglist.de/mailingl ... s_cron.htm ist der Aufruf mit wget erklärt.
Das Skript wird im Cronjob, mit den Rechten des VHosts ausgeführt, auf dem auch die SML eingerichtet ist. Folgendermaßen sieht der Eintrag in der Crontab aus:
Wir nutzen also die PHP-Kommandozeile. Dass der Cronjob tatsächlich ausgeführt wird, haben wir mit einer temporären Änderung, einem externen Logging überprüft.
Eine Idee wo der Fehler liegt? Wir nutzen ein Debian-Lenny-System und PHP via FCGI, falls das hier von Relevanz ist
Code: Alles auswählen
# m h dom mon dow command
*/1 * * * * php /var/www/example.com/web/newsletter/supermailingslist/crons.phpEine Idee wo der Fehler liegt? Wir nutzen ein Debian-Lenny-System und PHP via FCGI, falls das hier von Relevanz ist
das gibt es doch gar nicht. Wird das Script vom CronJob auch per wget ausgeführt? Steht im error_log des Servers vielleicht irgendwas drin wie Access denied oder so etwas?
Wenn der Aufruf per wget erfolgt, dann die -O und -o /dev/null mal weglassen und hinten an das crons.php?language=de anhängen, so dass Meldungen ausgegeben werden. Diese Meldungen müssten dann per Mail an den Admin geschickt werden bzw. im (meistens) /root/ Verzeichnis müssten sich lauter crons.php.0 crons.php.1 crons.php.2 usw. Dateien mit den Meldungen des Scripts befinden.
Wenn der Aufruf per wget erfolgt, dann die -O und -o /dev/null mal weglassen und hinten an das crons.php?language=de anhängen, so dass Meldungen ausgegeben werden. Diese Meldungen müssten dann per Mail an den Admin geschickt werden bzw. im (meistens) /root/ Verzeichnis müssten sich lauter crons.php.0 crons.php.1 crons.php.2 usw. Dateien mit den Meldungen des Scripts befinden.
Hallo Mirko,
um die Bounces von Emails zu prüfen, nutzen wir die entsprechende Funktion in der SML. Einen entsprechenden Cronjob haben wir eingerichtet, der läuft auch minütlich. Allerdings passiert in der SML nichts, also er prüft nicht auf unzustellbare Mails etc. Wenn ich die Aufgaben manuell ausführe geht alles. Die Bounces soll er alle 30min prüfen. Unser Cronjob, der die crons.php aufrufen soll läuft minütlich. Unser Cronjob läuft hundertprozentig. Unser Server-Admin hatte mal aus Testzwecken deine crons.php angepasst und hat bei jedem Aufrufen das aktuelle Datum und Zeit in eine TXT-Datei schreiben lassen. In der TXT haben wir gesehen, dass die crons.php minütlich ausgeführt wurde.
An was könnte das nun liegen? Wie gesagt, die crons.php wird regelmäßig ausgeführt. Aber die Mails werden nicht auf Bounces analysiert. Das Ereignisprotokoll bleibt da auch leer. Es sei denn ich starte die Aufgaben manuell. Dann wird auf Bounces geprüft und im Ereignisprotokoll ist das auch sichtbar.
LG,
Sebastian
um die Bounces von Emails zu prüfen, nutzen wir die entsprechende Funktion in der SML. Einen entsprechenden Cronjob haben wir eingerichtet, der läuft auch minütlich. Allerdings passiert in der SML nichts, also er prüft nicht auf unzustellbare Mails etc. Wenn ich die Aufgaben manuell ausführe geht alles. Die Bounces soll er alle 30min prüfen. Unser Cronjob, der die crons.php aufrufen soll läuft minütlich. Unser Cronjob läuft hundertprozentig. Unser Server-Admin hatte mal aus Testzwecken deine crons.php angepasst und hat bei jedem Aufrufen das aktuelle Datum und Zeit in eine TXT-Datei schreiben lassen. In der TXT haben wir gesehen, dass die crons.php minütlich ausgeführt wurde.
An was könnte das nun liegen? Wie gesagt, die crons.php wird regelmäßig ausgeführt. Aber die Mails werden nicht auf Bounces analysiert. Das Ereignisprotokoll bleibt da auch leer. Es sei denn ich starte die Aufgaben manuell. Dann wird auf Bounces geprüft und im Ereignisprotokoll ist das auch sichtbar.
LG,
Sebastian