Cronjob startet nicht / Magic Button

  • Thread starter Thread starter ATLAS
  • Start date Start date
A

ATLAS

Guest
Was habe ich?
Rootserver von Strato
Original Image Suse 10.2 mit Serveradmin24

Was möchte ich?
Einen einfachen Cronjob für mysqldumper als user (nicht root) einrichten.

Vorgeschichte
Ich habe diesen Server schon sehr lange. Er lief bis vor kurzem noch mit dem alten Visas. Nun habe ich ihn neu aufgesetzt um einen aktuellen Stand zu bekommen. Ich hatte bisher niemals Probleme mit Cronjobs. Mit dem aktuellen SA24 aber bekomme ich es nicht hin. Ich sitze schon seit Tagen daran und habe auch im Internet rauf und runter gesucht. Bisher ohne Erfolg.

Was weiss ich und was habe ich getan?
Ich habe als allererstes, als noch kein Problem zu vermuten war, ganz normal den Cronjob eingerichtet. Der Befehl zum ausführen des Jobs lautet:
Code: 
perl /srv/www/meinedomain.info/public_html//cgi-bin/crondump.cgi config=mysqldumper.conf.php
Der Job selber wurde mit crontab -e angelegt und lautet:
Code: 
0 1  * * * perl /srv/www/meinedomain.info/public_html//cgi-bin/crondump.cgi config=mysqldumper.conf.php
Es wurde kein Job ausgeführt. Nun habe ich in der Vergangenheit die Tücken von Shell, bash und der Gleichen kennen gelernt.
In der Shell wir der Befehl
Code: 
perl /srv/www/meinedomain.info/public_html//cgi-bin/crondump.cgi config=mysqldumper.conf.php
korrekt ausgeführt.
Ich habe versucht in den log-Dateien etwas zu finden. Das ist mir nicht gelungen, es findet sich kein Hinweis auf einen Fehler. Um die Sache erst mal von vorn anzugehen, habe mir eine testdatei erstellt mit folgendem Inhalt:
crontest.sh
Code: 
echo crontest1 >> crontext | date >> datefile
Der direkte Aufruf in der Shell klappt problemlos. Als Cronjob geht es nicht.
Nun habe ich mir gedacht, ich schaue mir mal die Funktion "Magic Button" an.
Der Aufruf des Codes
Code: 
perl /srv/www/meinedomain.info/public_html//cgi-bin/crondump.cgi config=mysqldumper.conf.php
Klappt problemlos und wird auch im Fenster abgearbeitet. Offensichtlich gibt es ein anderes Problem. Also habe ich meine Testdatei aufrufen wollen mit:
Code: 
srv/www/meinedomain.info/crontest1.sh
Das Ergebnis lautet:
Code: 
srv/www/meinedomain.info/crontest1.sh: line 1: crontext: Permission denied
srv/www/meinedomain.info/crontest1.sh: line 1: datefile: Permission denied
Ich habe es in allen Varianten probiert. Auch mit #!/bin/bash als *.sh . Ich vermute, das ein ähnliches Problem beim Cronjob die Ursache ist.

Wenn jemand das Problem ebenfalls hat und womöglich eine Lösung, dann würde ich mich sehr freuen. Ich habe nun keine Idee mehr, woran es liegen könnte oder wie man das austricksen könnte.

Gruss
ATLAS
 
Bei Cronjobs und Shellskripten immer den vollständigen Pfad zu allen Programmen und Dateien angeben. Niemals relative Pfade benutzen.
 
Normalerweise mache ich das immer mit $HOME/dateiname. Das hat bisher immer tadellos geklappt. Ich habe das damals von der Strato-Hilfeseite übernommen und damit zum Beispiel immer meinen JK2-Server per Cronjob überwacht. Die verwendeten Skripte habe ich ja eins zu eins übernommen und war verwundert, das sie nun nicht mehr funktionieren.
Für unser Beispiel habe ich es nur vereinfacht. Du hast aber Recht. Korrekt muss es heissen:
Code: 
echo crontest1 >> /srv/www/meinedomain.info/crontext | date >> /srv/www/meinedomain.info/datefile
Zumindest wird mit diesem Befehl der Magic-Button abgearbeitet. Der cronjob funktioniert nach wie vor nicht.

Es würde eventuell helfen, wenn andere melden würden, ob und wie es bei ihnen funktioniert.

Gruss
ATLAS
 
ATLAS said:
Der cronjob funktioniert nach wie vor nicht.
Click to expand...

Was heißt "funktioniert nicht"? Die Ausgaben des cronjobs werden dem Besitzer per Mail zugestellt -- da sollte auf jeden Fall was drinstehen.

Nebenbemerkung: die Pipe ist absolut sinnlos. Wenn schon muss das ganze so aussehen:
Code: 
echo crontest1 >> /srv/www/meinedomain.info/crontext [COLOR="Red"]||[/COLOR] date >> /srv/www/meinedomain.info/datefile
 
Ich danke für den Hinweis, ich werde das korrigieren. Das lief nun drei Jahre so mit einer pipe. Aber das kann sich ja ändern.

Eine Mail habe ich noch nie erhalten. Auch damals nicht, als alles funktionierte. "Funktioniert nicht" soll heissen, der Job wird nicht abgearbeitet.

Gruss
ATLAS
 
Off-Topic: Wobei man noch anmerken sollte, dass "||" nicht in jedem Fall das ist, was Du brauchst (Ausführung, wenn der erste Teil nicht geklappt hat), sondern auch "&&" (Ausführung, nur wenn der erste Teil geklappt hat) und ";" (Ausführung in jedem Fall) in Frage kommen ;)
 
Es ist ja auch lediglich ein Testskript, um zu sehen, ob überhaupt etwas passiert.
Da aber nichts passiert, steht das Problem weiterhin im Raum. :(

Gruss
ATLAS
 
Die Lösung ist einfacher als man denkt!

Hatte mich auch gewundert, dass Cronjobs nicht übernommen werden.

Gib in der Shell mal ein

rccron restart

Dann startet er den Cron-Daemon neu, und lädt das neue Crontab rein. Scheint bei den vorkonfigurierten Strato-Servern wohl immer so zu sein, dass der Crontab nicht automatisch übernommen wird.

Ich hoffe, dass ich helfen konnte :)
 
Herzlichen Dank, das hat geholfen :).
Es scheint so zu sein, als ob der Neustart zwingend ist. Das werde ich noch probieren.
Ich werde berichten, was geht und was nicht.

Gruss
ATLAS
 
Der neuangelegte Cronjob startet tatsächlich ausschliesslich über den Neustart mit dem Befehl:
Code: 
 rccron restart
Dieser kann aber bequem über den Magic Button erfolgen. Den Code einfach ins Feld eingeben und als root ausführen lassen.

Als Testskript habe ich eine Datei mit Namen crontest1.sh angelegt mit folgendem Inhalt:
Code: 
echo "hallo" >>Hallo | date>>date1
Das sollte 2 Dateien mit dem Namen Hallo und date1 erzeugen. Im Inhalt befindet sich dann das Wort Hallo und in der anderen das Datum der Aktion.
Ich habe es mit einer Pipe, da 2 bei mir nicht funktionieren. Es geht aber auch mit &&.

Der Cronjob wir am besten in der shell angelegt da, SA24 das minütliche bei mir nur sporadisch übernimmt.
Also Crontab -e
i
*/1 * * * * /srv/www/meinedomain.info/crontest1.sh
ESC
:
wq

Danach noch rccron restart mit dem Magic Button.

Das sollte zum gewünschten Ergebnis führen.
Herzlichen Dank nochmal für die Hilfe von keksausmainz.

Gruss
ATLAS
 
Hallo,

das wäre wohl der Patch damit der Cron automatisch neugestartet wird.

Code: 
--- lib/cron.inc.php  
+++ lib/cron.inc.php
@@ -121,10 +121,9 @@
                $output = vc_exec_command("chown $user $crontab_path/$user", "root", $error_str);
                $output = vc_exec_command("chgrp $SYSTEM_CONF[crontab_group] $crontab_path/$user", "root", $error_str);
                $output = vc_exec_command("chmod 600 $crontab_path/$user", "root", $error_str);
                if(strpos($output, "No such file or directory")!==false) return false;
                else{
-                       service_reload("cron");
+                       service_restart("cron");
                        return true;
                }
        }

Gruss,
todin
 
Danke für den Tip.
Wäre das einzutragen in:
usr/local/sa24/public_html/domainadminlevel/redirect.php
?

Gruss
ATLAS
 
Hm, mir ist die Vorgehensweis noch nicht ganz klar. Verstehe ich es richtig, das der Patch folgenden Originaleintrag ersetzen soll?
Code: 
    $tmp_file = "/usr/local/sa24/tmp/crontab_$user_".time();
        textdatei_schreiben($tmp_file, $data);
        $output = vc_exec_command("mv $tmp_file $crontab_path$user", "root", $error_str);
        $output = vc_exec_command("chown $user $crontab_path$user", "root", $error_str);
        $output = vc_exec_command("chgrp $SYSTEM_CONF[crontab_group] $crontab_path$user", "root", $error_str);
        $output = vc_exec_command("chmod 600 $crontab_path$user", "root", $error_str);
        if(strpos($output, "No such file or directory")!==false) return false;
        else{
            service_reload("cron");
            return true;
        }
    }

Gruss
ATLAS
 
Es geht genau um diese Zeile:

service_reload("cron");

Austauschen gegen

service_restart("cron");

Gruß
Uwe
 
Ich danke euch beiden :)
Möglicherweise wäre es generell nicht schlecht, die zu ändernde Stelle mit dazu zu schreiben. Zumindest aber der Dateiname würde enorm weiter helfen. Denn ihr hat ja schon etliches an "Patches" gepostet und es wäre schade, wenn jemand das nicht benutzt, weil es sich nicht traut zu fragen ;).

Gruss
ATLAS
 
All diese Informationen sind im Patch enthalten. Die Angaben sind relativ zum Basis-Verzeichnis des zu patchenden Pakets. Da der absolute Pfad von Installation zu Installation unterschiedlich ist, sollten diese Informationen ausreichen.
Wer zu faul zum manuellen Einfügen ist, nimmt das Tool 'patch'.

Dazu muss man die erste Seite dieses Thread (die den patch enthält) als TXT abspeichern und dann
Code: 
cd sa24-Verzeichnis
patch -p0 < /pfad/zur/txt/datei
eingeben. Patch kann sich die Informationen aus plain-text-Dateien selbständig extrahieren. So einfach ist das ;)
 
Ich mache das lieber per Hand. Ich habe nochmal nachgeschaut. Wenn hinter dem ---/+++ die Datei gemeint ist, dann reicht mir das völlig aus.;)

Ich danke für den Hinweis.

Gruss
ATLAS
 
You must log in or register to reply here.
Back
Top