[S4Y] Cronjobs werden nicht ausgeführt

Status
Not open for further replies.

phil

Registered User
Hallo,

ich besitze einen "POWER" Rootserver von Server4You und mir ist neuerdings aufgefallen, dass meine Cronjobs, die ich per "crontab -e" über SSH (Putty) eingetragen habe, komischerweise nicht ausgeführt werden.

Das ganze sieht folgendermaßen aus:

Code:
-*/2 * * * *   /usr/local/confixx/confixx_counterscript.pl
-37 2 * * * /usr/local/confixx/auto_reg.pl 2>/dev/null >/dev/null
37 2 * * * /usr/sbin/netdate ntp1.intergenia.de 2>/dev/null >/dev/null && hwclock -w 2>/dev/null >/dev/null
0 */6 * * * /usr/local/confixx/runwebalizer.sh 2>/dev/null >/dev/null
5 0 * * * /srv/www/htdocs/web1/html/cronjobs/cronjob.7day.notify_haendler_users.php
10 0 * * * /srv/www/htdocs/web1/html/cronjobs/cronjob.7day.notify_private_users.php
15 0 * * * /srv/www/htdocs/web1/html/cronjobs/cronjob.equalize.h_kont_akt.php
20 0 * * * /srv/www/htdocs/web1/html/cronjobs/cronjob.equalize.ss_kont_akt.php
25 0 * * * /srv/www/htdocs/web1/html/cronjobs/cronjob.equalize.zub_kont_akt.php
30 0 * * * /srv/www/htdocs/web1/html/cronjobs/cronjob.equalize.zub_ss_akt.php
35 0 * * * /srv/www/htdocs/web1/html/cronjobs/cronjob.optimize.tf_logins.php
40 0 * * * /srv/www/htdocs/web1/html/inc/backup.pics.php
45 0 * * * /srv/www/htdocs/web1/html/inc/mysql.dump.backup.php

Alle Cronjobs des Kunden "web1" habe ich zusätzlich eingetragen (die oberen waren dort schon drin) und diese scheinen auch alle leider nicht ausgeführt zu werden.

Weiterhin ist noch zu sagen, dass alle PHP-Scripte, die dort ausgeführt werden sollen bei einem manuellen Aufruf problemlos funktionieren. Fehler in diesen Scripten sind also auszuschließen.

Weiss vielleicht jemand, welche Ursachen das haben kann und wie ich dieses Problem vielleicht beheben kann?

Bin für jegliche Hilfe dankbar!

phil :)
 
Ich denke mal, dass cron bei dir nicht läuft.
Check:
Code:
/etc/init.d/cron status
not running?
Code:
/etc/init.d/cron start

Good luck ;)
 
phil said:
Das ganze sieht folgendermaßen aus:
Das kann viele Gründe haben.

1. Frage:
Laufen denn die oberen Confixx-Cronjobs? (erkennbar z.B. am Webalizer)

2. Frage:
Was meinst Du mit 'manuellen start'?
Typische Symptome sind hierbei z.B. nicht die nötigen Ausführungsrechte, keine Shebang-Zeile, aus dem falschen Verzeichnis heraus gestartet, ohne Interpreter (php als cli), etc.

huschi.
 
server4downs said:
Ich denke mal, dass cron bei dir nicht läuft.
Check:
Code:
/etc/init.d/cron status
not running?
Code:
/etc/init.d/cron start

Good luck ;)

Cron scheint zu laufen.

Code:
oslo073:~ # /etc/init.d/cron status
Checking for Cron:                                                   running



Sandmann said:
Also wenns ums manuelle eintragen geht, benutze ich /etc/cron.d

Also du musst wissen, dass ich davon sogut wie keine Ahnung habe, wenn ich nach dem Einloggen als root auf meinem Server mittels Putty "/etc/cron.d" eingebe, dann bekomme ich als Rückmeldung: "-bash: /etc/cron.d: is a directory".
Wäre sehr nett, wenn du das noch etwas weiter erläutern könntest.



Huschi said:
1. Frage:
Laufen denn die oberen Confixx-Cronjobs? (erkennbar z.B. am Webalizer)

Ja, also der Webalizer läuft.


Huschi said:
2. Frage:
Was meinst Du mit 'manuellen start'?
Typische Symptome sind hierbei z.B. nicht die nötigen Ausführungsrechte, keine Shebang-Zeile, aus dem falschen Verzeichnis heraus gestartet, ohne Interpreter (php als cli), etc.

Mit "manuellem Start" meine ich das Aufrufen des PHP-Scripts über den Browser, das klappt ohne Probleme. Es ist also nicht so, dass die PHP-Scripte fehlerhaft sind.
Dass die Ausführungsrechte nicht stimmen, könnte sein. Wie überprüfe ich das ? Wie gesagt, ich habe noch nicht allzuviel Erfahrung mit Linux und auch nicht wirklich mit SSH etc.
Hmmm, ich überlege gerade, was eine Shebang-Zeile ist. :)
Das/die Verzeichnis(se) sollte(n) so stimmen, habe es grad nochmals mit dem Midnight Commander geprüft.
Ohne Interpreter, ja könnte auch sein. Wie sage ich denn dem Cron, dass er das auszuführende Script durch den PHP-Interpreter jagen soll ?


Soweit schonmal vielen Dank für die Hilfe! Ich hoffe aber, dass ihr noch etwas Geduld mit mir habt und mir weiterhelft. :)

phil
 
phil said:
Mit "manuellem Start" meine ich das Aufrufen des PHP-Scripts über den Browser, das klappt ohne Probleme.
Das habe ich mir gedacht... ;)

Es macht große Unterschiede, ob Du sie im Browser testest oder per Cron oder ssh:
1. Benutzerrechte bei der Ausführung
2. Benutzerrechte der Datei müssen auf 'ausführbar' stehen und eine shebang-Zeile ('#!/usr/bin/php') am Anfang enthalten.
3. Das Startverzeichnis ist undefiniert.

Lösung:
Ändere die Crontab wie folgt ab:
Code:
5 0 * * * cd /srv/www/htdocs/web1/html/cronjobs/; php cronjob.7day.notify_haendler_users.php

huschi.
 
Vielen Dank!

Ich habe jetzt die Benutzerrechte richtig eingestellt, diese Shebang-Zeile in meine Scripte eingefügt und den Crontab, so wie du es vorgeschlagen hast, geändert. Und siehe da, fast alle Cronjobs werden nun ordnungsgemäß ausgeführt.
"Fast alle", weil das letzte Script (MySQL DB Backup) immer noch Probleme macht.

Vielleicht hilft dir/euch die Mail an den root ("vi /var/mail/root") zu diesem Cronjob:

Code:
From: root@oslo073.server4you.de (Cron Daemon)
To: root@oslo073.server4you.de
Subject: Cron <root@oslo073> cd /srv/www/htdocs/web1/html/inc/; php mysql.dump.backup.php
X-Cron-Env: <SHELL=/bin/sh>
X-Cron-Env: <HOME=/root>
X-Cron-Env: <PATH=/usr/bin:/bin>
X-Cron-Env: <LOGNAME=root>

sh: line 1: /backups/24_12_2004.sql.gz: No such file or directory
Content-type: text/html
X-Powered-By: PHP/4.3.9

Ort d. Dumps: /backups/24_12_2004.sql.gz<br>DONE!

Also ich sehe selber an der Fehlermeldung "No such file or directory", dass er irgendwie nicht in diese Datei schreiben kann, weil es sie nicht gibt, aber ich verstehe nicht warum.


Vielleicht ist hierzu auch der PHP-Code zu diesem Script hilfreich:

PHP:
#!/usr/bin/php
<?php
	include("mysql.cfg.inc.php");

  	$backupdir = 'backups/';

  	// Datum fuer den Dump-Namen
  	$now = date("d_m_Y");

  	// Ausfuehren des mysqldump Befehls in der Shell
  	system('/usr/bin/mysqldump --opt -h'.MYSQL_HOST.' -u'.MYSQL_USER.' -p'.MYSQL_PASS.' '.MYSQL_DATABASE.' | /bin/gzip > '.$_SERVER['DOCUMENT_ROOT'].'/'.$backupdir.$now.'.sql.gz');

  	echo 'Ort d. Dumps: '.$_SERVER['DOCUMENT_ROOT'].'/'.$backupdir.$now.'.sql.gz<br>';
  	echo 'DONE!';
?>

Also für mich sieht es so aus, als würde der Wert der Superglobal-Variable $_SERVER['DOCUMENT_ROOT'] beim Aufruf über einen Cronjob nicht existieren. Denn wenn ich das Script per Browser manuell aufrufe, dann bekomme ich als Return z.B.:
"Ort d. Dumps: /srv/www/htdocs/web1/html/backups/24_12_2004.sql.gz <br> DONE!" und wie man an der Mail zum root sehen kann, wird beim Ausführen des Scripts per Cronjob der Pfad zum Script nicht absolut ausgegeben (sprich ohne Inhalt der Variable: $_SERVER['DOCUMENT_ROOT']).

Es wäre sehr nett, wenn ihr mir hier auch nochmals helfen könntet. :)

Ansonsten frohe Weinachten!
phil
 
include("mysql.cfg.inc.php");
$backupdir = 'backups/';

ist falsch

ich würde

include("PFAD/ZU/mysql.cfg.inc.php");

und

$backupdir = '/backups/';

nehmen :)

$_SERVER['DOCUMENT_ROOT'] komplett raus da dieses nicht unter Console funktoniert bei einem Cronjob
 
society said:
include("mysql.cfg.inc.php");
$backupdir = 'backups/';

ist falsch
hoppla, über diese Aussage würde ich mir nach dem Geschenkeauspacken nochmals paar Gedanken zu durch den Kopf gehen lassen ;)
Wenn das File im gleichen Verzeichnis liegt, dann funst das super, auch ohne Path-Angabe.
 
Hehehe,

recht hast du schon ganz falsch ist das nicht aber sicher ist sicher...
Lieber im Cronjob alles mit festen Pfaden machen so fällt man nicht auf dem Kopf.. so erstmal Essen gehen und dann Geschenke auspacken *G*
 
Alles klar! Vielen Dank!

Ich habe das $_SERVER['DOCUMENT_ROOT'] jetzt durch einen absoluten Pfad ersetzt und es läuft!

Okay, also ich denke somit hätten wir alles geklärt.

phil :)
 
/etc/init.d/cron status

No such file or directory...

Kann es sein, dass cron nicht installiert ist ?

Wenn es so ist, wie installiere ich es ? habe ein vserver bei server4you
 
 
Status
Not open for further replies.
Back
Top