nicht angemeldet
curl oder wget in einer bash
MudGuardGuten Morgen, liebe Leuts.
Ich hab da ein Problem dem ich nicht Herr werde und das mich langsam aber sicher zum Verzweifeln bringt, weil ich schon alles versucht habe und immer wieder unterschiedliche Ergebnisse bekomme.
Ausgangssituation:
Wir haben einen linux-server (managed) bei 1&1 mit einer gut befüllten mysql-datenbank laufen. desweiteren laufen dort verschiedene php-skripte über cronjobs, die Routine-Aufgaben erledigen sollen (z.b. automatisierte Importe in die DB, Check des file-systems etc.). Vereinzelte jobs laufen zu verschiedenen
Uhrzeiten und bestimmten Tagen.
Allerdings gibt es ein bash-Skript, das immer 5 minuten nach Mitternacht jeden Tag läuft. Diese bash beinhaltet unterschiedliche Aufrufe, die entweder selber noch ein bash-Skript aufrufen oder ein PHP-skript ausführen sollen. Das Wichtige an diesem Skript ist allerdings, dass alles sequentiell hintereinander weg läuft, weil einige Routinen erst ausgeführt werden dürfen, wenn die vorherigen erledigt worden sind.
z.B.:
- Aufruf eines bash-Skriptes, das eine Datei per FTP holt und entpackt
- Aufruf eines PHP-Skriptes, das diese Datei öffnet und verschiedene Operationen ausführt und die modifizierten Daten in die DB schreibt.
- Wiederholung der Aktionen mit anderen Dateien
#!/bin/bash
DATUM=$(date +"%Y%m%d")
LOG_DIR=/*********/logs/${DATUM}
mkdir ${LOG_DIR}
/********/htdocs/download1.sh
curl -u username:password --url www******.**/import1.php > ${LOG_DIR}/${DATUM}_import1.log
/********/htdocs/download2.sh
curl -u username:password --url www.*****.**/import2.php > ${LOG_DIR}/${DATUM}_import2.log
-----------------------------
Schreib und Leserechte sind gesetzt, kein Problem. Und wenn ich dieses Skript per Hand ausführe läuft auch alles richtig und ohne Probleme durch, meine Log-files enthalten gut gefüllte Ausgaben aus den PHP-Skripten, die auch bis zum Ende durchlaufen und keine Fehler sind sichtbar.
Wenn ich allerdings den Job um 0:05 ausführen lasse, bekomme ich von allen curl-Aufrufen ein leeres log-file zurück.
Man muss dazu vielleicht noch sagen, dass das erste PHP-Skript verhältnismässig schnell durchgeht (ca. 6min - also normal) und das 2. Skript ca. 1:30 braucht (was aber, wenn man die Skripte einzeln für sich durchlaufen lässt, auch normal ist).
Mein Frage ist nun, was ist für so einen Ablauf besser geeignet? curl oder wget? wo sind die Unterschiede und warum bekomme ich mit wget, wenn ich im Skript 5-6 PHP-Skripte nacheinander aufrufe manchmal komplett leere log-files zurück? Gibt es eine Möglichkeit die Exitcodes oder Errorlevel nach jedem wget- oder curl-Aufruf zu überprüfen, damit man im Skript schon irgendwie handeln kann?
Ich wäre um jede Anregung oder jeden Tipp sehr dankbar,
Gruss, Peter
--
If kids had been influenced by Pacman, they'd be jumping around in dark rooms eating strange pills and listening to monotonous music these days.
If kids had been influenced by Pacman, they'd be jumping around in dark rooms eating strange pills and listening to monotonous music these days.
-
Hi,
Wenn ich allerdings den Job um 0:05 ausführen lasse, bekomme ich von allen curl-Aufrufen ein leeres log-file zurück.
Und wenn ich dieses Skript per Hand ausführe läuft auch allesunter einer anderen User-Umgebung als wenn es als cron-job ausgeführt wird.
D.h., daß der Pfad (in dem nach auszuführenden Dateien gesucht wird) ein anderer sein kann, daß andere Schreibrechte erforderlich sein können usw.Gegen ersteres hilft z.B., immer komplette Pfade zu den betroffenen Dateien anzugeben.
Gegen zweiteres hilft chmod.cu,
Andreas--
Warum nennt sich Andreas hier MudGuard?
O o ostern ...
Fachfragen unaufgefordert per E-Mail halte ich für unverschämt und werde entsprechende E-Mails nicht beantworten. Für Fachfragen ist das Forum da.
-
Danke, Andreas, für die erste Antwort ^^
»» »» Wenn ich allerdings den Job um 0:05 ausführen lasse, bekomme ich von allen curl-Aufrufen ein leeres log-file zurück.
»» »» Und wenn ich dieses Skript per Hand ausführe läuft auch alles
»»
»» unter einer anderen User-Umgebung als wenn es als cron-job ausgeführt wird.
»» D.h., daß der Pfad (in dem nach auszuführenden Dateien gesucht wird) ein anderer sein kann, daß andere Schreibrechte erforderlich sein können usw.
»»
»» Gegen ersteres hilft z.B., immer komplette Pfade zu den betroffenen Dateien anzugeben.
»» Gegen zweiteres hilft chmod.die Pfade in den bash-skripten und in den PHP-Dateien sind absolut. Und wenn ich den cronjob auf meinetwegen 8:00 setze funktioniert alles reibungslos.
Ein weiteres Phänomen: Manchmal bricht ein PHP-Skript mitten in der Ausführung ab und alle nachfolgenden Logs sind dann leer. *verzweifelt-dreinblick*Gruss, Peter
--
If kids had been influenced by Pacman, they'd be jumping around in dark rooms eating strange pills and listening to monotonous music these days.-
echo $begrüßung;
Und wenn ich dieses Skript per Hand ausführe läuft auch alles
unter einer anderen User-Umgebung als wenn es als cron-job ausgeführt wird.
die Pfade in den bash-skripten und in den PHP-Dateien sind absolut.Das ist in deinem Beispiel so nicht zu sehen. curl steht einfach so da und nicht als /usr/bin/curl, oder wo auch immer es installiert ist.
Und wenn ich den cronjob auf meinetwegen 8:00 setze funktioniert alles reibungslos.
Eigenartig, aber es gibt dafür sicher eine Erklärung.
Ein weiteres Phänomen: Manchmal bricht ein PHP-Skript mitten in der Ausführung ab und alle nachfolgenden Logs sind dann leer. *verzweifelt-dreinblick*
Konfiguriere lieber ein Error-Logging in eine Datei. Cronjobs haben die Eigenart, Fehler (also Ausgaben der beteiligten Programme nach stderr) per Mail an den Benutzer zu versenden, unter dem der Cronjob läuft. Da du nicht erwähntest, dass da keine Post ankommt, gehe ich davon aus, dass du auch dort noch nicht nachgesehen hast.
P.S. Bitte die Zitatzeichen unverändert lassen.
echo "$verabschiedung $name";
-
Moinsen,
echo $begrüßung;
Und wenn ich dieses Skript per Hand ausführe läuft auch alles
unter einer anderen User-Umgebung als wenn es als cron-job ausgeführt wird.
die Pfade in den bash-skripten und in den PHP-Dateien sind absolut.Das ist in deinem Beispiel so nicht zu sehen. curl steht einfach so da und nicht als /usr/bin/curl, oder wo auch immer es installiert ist.
Und wenn ich den cronjob auf meinetwegen 8:00 setze funktioniert alles reibungslos.
Eigenartig, aber es gibt dafür sicher eine Erklärung.
Ein weiteres Phänomen: Manchmal bricht ein PHP-Skript mitten in der Ausführung ab und alle nachfolgenden Logs sind dann leer. *verzweifelt-dreinblick*
Konfiguriere lieber ein Error-Logging in eine Datei. Cronjobs haben die Eigenart, Fehler (also Ausgaben der beteiligten Programme nach stderr) per Mail an den Benutzer zu versenden, unter dem der Cronjob läuft. Da du nicht erwähntest, dass da keine Post ankommt, gehe ich davon aus, dass du auch dort noch nicht nachgesehen hast.
P.S. Bitte die Zitatzeichen unverändert lassen.
echo "$verabschiedung $name";
Danke, für all die Antworten. Aber das Problem liegt wohl an einer ganz anderen Stelle.
Der Aufruf eines Bash-Skriptes innerhalb eines Bash-Skriptes funktioniert nicht sequentiell, heisst wenn ein Bash-Skript aufgerufen wird, wird nicht auf die Antwort gewartet, sondern gleich mit dem nächsten Kommando weitergemacht. Die Indifferenz liegt also zwischen dem Bash-Skript Aufruf und dem nachfolgenden curl-Aufruf. Das Bash-Skript wird ausgeführt und parallel läuft curl schon los. Und schon kommt es zu Problemen.
Gruss, Peter
--
If kids had been influenced by Pacman, they'd be jumping around in dark rooms eating strange pills and listening to monotonous music these days.
-
-
-
-
Hi PeTaGeh,
Gibt es eine Möglichkeit die Exitcodes oder Errorlevel nach jedem wget- oder curl-Aufruf zu überprüfen, damit man im Skript schon irgendwie handeln kann?
In der Shell-Variable ? steht der Rückgabewert.
Wie gewohnt ist in der Shell mal wieder alles anders. Bei einer 0 ist alles OK und bei einem Wert ungleich 0 ist ein Fehler aufgetreten.
Die Exit Code sollten in der entsprechenden manpage stehen.MfG
Otto