Support-Forum Mirko Böer Softwareentwicklungen

Hm, ja, dummer Fehler von mir, und das obwohl ich das FAQ von HE bestimmt 5 mal durchgelesen hab, sorry

Der Fehler ist zwar jetzt weg, es sind aber keinerlei Anzeichen zu sehen das der cronjob ausgeführt wird. Auch in den SML Ereignissen ist nichts zu sehen.
Hab deshalb mal testweise den cronjob bei cronjob.de eingestellt und bei HE deaktiviert. Und das funktioniert.

Muß ich wohl mal den HE support kontaktieren.

Siehe dazu Hosteurope FAQ http://faq.hosteurope.de/index.php?cpid=13519 dort ist der Fehler "/usr/local/bin/php^M: bad interpreter: No such file or directory" auch erklärt und wie man diesen behebt.

Wollte den Cronjob für SML bei Host Europe einrichten. Der läuft zwar, bringt mir aber diese Fehler:

Mit der original crons.php Datei:
/is/htdocs/wp10455169_7OY4YY66BO/newsletter/crons.php: line 1: ?php
: No such file or directory
/is/htdocs/wp10455169_7OY4YY66BO/newsletter/crons.php: line 26: syntax error near unexpected token `"config.inc.php"'
/is/htdocs/wp10455169_7OY4YY66BO/newsletter/crons.php: line 26: ` include_once("config.inc.php");


Mit #!/usr/local/bin/php in der ersten Zeile: (von anderem cronjob welcher ok läuft abgeschaut)
/bin/sh: /is/htdocs/wp10455169_7OY4YY66BO/newsletter/crons.php: /usr/local/bin/php^M: bad interpreter: No such file or directory

hab keine Ahnung von cronjobs und an was das liegen könnte, jemand hier vielleicht?


Der Link zu der website in der Vorpost ist leider tot, kann ich nicht mehr nachlesen

Wenn du die Sache mit dem shebang verwendest, dann darfst du das Script nicht mit wget aufrufen, sondern einfach so angeben und natürlich die Rechte auf \"Ausführen\" vorher setzen.

Moin,

das Einfügen von error_reporting(E_ALL); bringt keine Änderung. Die Datei ist weiterhin leer.

Hier nochmal die FAQ von HE zum Thema:



Befehl:
Der Pfad des auszuführenden Programmes oder Skriptes. Er wird relativ zum Stammverzeichnis angegeben. Bitte beachten Sie, ...

* ...dass das Skript ausführbar (eXecutable) sein muß. Das Setzen von Dateisystemrechten/Dateiattributen ist hier beschrieben.
* ...der zuständige Interpreter (sog. \"shebang\", z.B. für PHP \"#!/usr/local/bin/php\") muss in der ersten Zeile des Skripts angegeben sein.

Wichtig: Bitte beachten Sie, dass Sie innerhalb Ihrer Skripte auch absolute Pfade benutzen müssen, die auf /is/htdocs/wpxxxxxxx_xxxxxxxxx/ verweisen.




setzt man wie hier gefordert den Interpreter in die erste Zeile erscheint genau diese erste Zeile (z.B. #!/usr/local/bin/php oder #!/usr/bin/php5) in den crons.php.X - Dateien.

\"Etwaige Aufgaben jetzt manuell ausführen\" liefert jetzt übrigens folgendes Ergebnis:
Script timeout at level 1.
Check options of email retrieving or for email sending.

... also Level 1 statt Level 5

Jens

Da steht ja auch nur etwas drin, wenn ein Fehler auftritt. Im Script crons.php oben nach <?php bzw. nach den ganzen Kommentaren reinschreiben error_reporting(E_ALL); und damit den Aufruf testen.

Wichtig: Das Script crons.php darf nur 1x pro Minute aufgerufen werden, wird es öfter aufgerufen, dann passiert gar nichts.

Moin,

hier das Protokoll der SSH Prozedur:




wpXXXXXXX@vwp1570:~$ cd /is/htdocs/wpXXXXXXX_MG081WCPYE/
wpXXXXXXX@vwp1570:/is/htdocs/wpXXXXXXX_MG081WCPYE$ /usr/bin/wget -O /dev/null -o /dev/null http://subdomain. domain. de/crons.php (da passiert NIX)
wpXXXXXXX@vwp1570:/is/htdocs/wpXXXXXXX_MG081WCPYE$ /usr/bin/wget http://subdomain. domain. de/crons.php
--22:29:13-- http://subdomain. domain. de/crons.php
=> `crons.php.4\'
Resolving subdomain.domain.de... 87.230.106.70
Connecting to subdomain.domain.de|87.230.106.70|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 0 [text/html]

[ <=> ] 0 --.--K/s

22:29:13 (0.00 B/s) - `crons.php.4\' saved [0/0]




Die crons.phpX Dateien sind leer. Nix drin.

Gruß Jens

Das cd /is/htdocs/wpxxxxxxx_MG081WCPYE/ per SSH selbst machen, danach mit wget das Script aufrufen, damit nicht -O /dev/null -o /dev/null angeben. Nach dem Aufruf sollte eine Datei crons.php.0 (1, 2, 3 usw..) in dem gleichen Verzeichnis liegen. Die Datei anschauen ob Fehlermeldungen enthalten sind.

Hallo,

bin jetzt erst wieder dabei. Das Problem war noch nicht gelöst.

hier der Inhalt der mycrons.php:

#!/bin/sh
cd /is/htdocs/wpxxxxxxx_MG081WCPYE/
/usr/bin/wget -O /dev/null -o /dev/null http://subdomain. domain. de/crons.php

die crons.php ist im Originalzustand.

Einstellungen bei Host Europe:


Resultat: es passiert nichts!

Per SSH habe ich es probiert. passiert aber auch nichts. Ist schon wieder ein paar Tage her. Aber wenn ich \"-O /dev/null -o /dev/null\" weglasse passiert was per SSH, allerding werden die E-mails auch nicht abgerufen.

ich komm so nicht weiter. Es raubt extrem viel Zeit da rumzuexperimentieren...

Ist der Ansatz falsch? Die sache mit dem Skript war ja nur eine Idee.

Hast du einen Shell-Zugriff (SSH) bei Hosteurope? Damit könnte man manuell den Aufruf mal testen.

also falsch ist das

/usr/bin/wget -O /dev/null -o /dev/null www/swm/crons.php

das muss sein

/usr/bin/wget -O /dev/null -o /dev/null http:// www. domain .de /swm/crons.pho

natürlich bei der http:// www. Angabe ohne Leerzeichen, die habe ich hier nur so angegeben, damit das Forum keine URL daraus macht.

Wäre das so richtig?

#!/bin/sh
cd /is/htdocs/wpxxxxxxxx_xxxxxxxxxxxxx/
/usr/bin/wget -O /dev/null -o /dev/null www/swm/crons.php


es gibt zwar wieder keine Fehlermeldungen, aber die bounces werden immer noch nicht abgerufen. ich verzweifle daran! Oder ist das Root Verzeichnis anders zu erreichen?

Das ganze in einer PHP-datei ohne <php>???

functions.inc.php und crons.php sind angepasst nach Anleitung.

Mit dem zusätzlichen Shell-Script sollte es gehen, du musst aber dann die Änderungen an der crons.php rückgängig machen, sonst wird PHP die crons.php nicht korrekt ausführen.

Im dem Shell-Script die Angabe

/usr/bin/wget -q http://mydomain/drupalinstall/cron.php
rm cron.php*

ändern, dass heißt rm cron.php* löschen. -q weglassen, an die Stelle des -q

-O /dev/null -o /dev/null

schreiben. -O und -o ist jeweils der Buchstabe O wie Otto, keine Null.


Nachtrag:
Zuätzlich die Datei functions.inc.php runterladen und im Editor öffnen. Im Editor nach @set_time_limit suchen und in die Zeile genau oben drüber einsetzen @ignore_user_abort(true); . Datei speichern und übertragen.

Moin,

schon klar. habe ich ja auch alles probiert. Unter folgendem Link habe ich etwas gefunden, was vielleicht hilft??? Link: cron jobs bei Host Europe dies Betrifft dort “WebPack Pro MAXâ€

Na eigentlich soll doch das Script per wget aufgerufen werden, das müsste auf dem Hosteurope-Servern auch installiert sein. Ruft man es nicht per wget auf und das Script braucht zu lange für die Aufrufe, z.B. Abruf von Bounces dauert lange, dann wird es abgebrochen. Tritt das ständig auf, dann wird er ab der Prüfung der Bounces nichts mehr tun. Es werden damit keine E-Mails versendet und keine Responder abgearbeitet, die kommen alle danach.

hallo,

ja, habs modifiziert. sonst ging es nicht!

Zitat Host Europe: \"der zuständige Interpreter (sog. \"shebang\", z.B. für PHP \"#!/usr/local/bin/php\") muss in der ersten Zeile des Skripts angegeben sein\"

Beispiel Host Europe:

#!/usr/local/bin/php
<?php ...

Wenn ich das rausnehme und das Script im Original belasse bekomme ich Fehlerreports per E-mail (Cron Daemon [root@hosteurope.de]):

/is/htdocs/.../www/swm/crons.php: line 1: ?php: No such file or directory
/is/htdocs.../www/swm/crons.php: line 27: syntax error near unexpected token `\"config.inc.php\"\'
/is/htdocs/.../www/swm/crons.php: line 27: ` include_once(\"config.inc.php\");\'

dann geht garnichts mehr.

vielen Dank für den schnellen Support!