2
Remote befehl mit dbclient rückgabewert bei cron ausführung verschwunden
Skript funktioniert bei normaler Ausführung, jedoch nicht bei Ausführung per cron/crontab (vmware esxi, busybox, /bin/sh)
Hallo,
ich habe ein Shell-Script auf unserem ESXi Server geschrieben, welches auf einem anderen ESXi Server einen Befehl ausführt ( df ).
Wenn ich das Script "per Hand" ausführe und den Rückgabewert ausgebe, funktioniert alles, wie es soll. Wenn ich das ganze in /var/spool/cron/crontab/root packe, funktioniert es nicht mehr und ich erhalte keinen Rückgabewert.
1. Hier das Skript (Minimalbeispiel):
#!/bin/sh
someval=$(/bin/dbclient -i /.ssh/serverx_rsa root@192.168.1.55 "df | grep Datastore | awk '{print $4 $6}'")
echo $someval > /tmp/returnvalue
dbclient ist der auf dem ESXi vorhandene dropbearclient, -i ist der rsa key (identity file) für Authentifizierung ohne Passwort.
2. Folgendes habe ich schon überprüft:
cronjob wird als root ausgeführt.
Die Verbindung zum Remote-Server funktioniert (erfolgreiche Verbindung steht in /var/log/messages auf Remote-Server und ein Aufruf mit touch /tmp/testfile anstatt df legte diese Datei an)
Am awk oder grep liegt's nicht, ein Ersetzen des auszuführenden Befehls mit "echo "hallo" oder nur "df" ergab ebenfalls keine Rückgabewerte.
Ich habe den auszuführenden Befehl mit und ohne " und in vielen Varianten ausprobiert....
Ich habe versucht, den Rückgabewert direkt auszugeben (mittels echo) und direkt in eine Datei umzuleiten.
Das einzige was ich mir noch vorstellen kann, wäre, dass der dbclient Befehl vom cron in einer subshell ausgeführt wird, allerdings müsste dann ein direktes Ausgeben per echo doch funktionieren. Außerdem würde es dann wahrscheinlich beim manuellen Ausführen auch nicht funktionieren.
Vielleicht hat ja jemand ne Idee!
Vielen Dank schonmal für Antworten,
asgaroth
Hallo,
ich habe ein Shell-Script auf unserem ESXi Server geschrieben, welches auf einem anderen ESXi Server einen Befehl ausführt ( df ).
Wenn ich das Script "per Hand" ausführe und den Rückgabewert ausgebe, funktioniert alles, wie es soll. Wenn ich das ganze in /var/spool/cron/crontab/root packe, funktioniert es nicht mehr und ich erhalte keinen Rückgabewert.
1. Hier das Skript (Minimalbeispiel):
#!/bin/sh
someval=$(/bin/dbclient -i /.ssh/serverx_rsa root@192.168.1.55 "df | grep Datastore | awk '{print $4 $6}'")
echo $someval > /tmp/returnvalue
dbclient ist der auf dem ESXi vorhandene dropbearclient, -i ist der rsa key (identity file) für Authentifizierung ohne Passwort.
2. Folgendes habe ich schon überprüft:
cronjob wird als root ausgeführt.
Die Verbindung zum Remote-Server funktioniert (erfolgreiche Verbindung steht in /var/log/messages auf Remote-Server und ein Aufruf mit touch /tmp/testfile anstatt df legte diese Datei an)
Am awk oder grep liegt's nicht, ein Ersetzen des auszuführenden Befehls mit "echo "hallo" oder nur "df" ergab ebenfalls keine Rückgabewerte.
Ich habe den auszuführenden Befehl mit und ohne " und in vielen Varianten ausprobiert....
Ich habe versucht, den Rückgabewert direkt auszugeben (mittels echo) und direkt in eine Datei umzuleiten.
Das einzige was ich mir noch vorstellen kann, wäre, dass der dbclient Befehl vom cron in einer subshell ausgeführt wird, allerdings müsste dann ein direktes Ausgeben per echo doch funktionieren. Außerdem würde es dann wahrscheinlich beim manuellen Ausführen auch nicht funktionieren.
Vielleicht hat ja jemand ne Idee!
Vielen Dank schonmal für Antworten,
asgaroth
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 163578
Url: https://administrator.de/contentid/163578
Ausgedruckt am: 26.11.2024 um 07:11 Uhr
2 Kommentare
Neuester Kommentar
Ich habe jetzt herausgefunden, dass es scheinbar daran liegt das beim Aufruf mit cron kein Terminal zugewiesen wird. Ich konnte dieses Problem durch das explizite zuweisen eines
Pseudoterminals zum Teil lösen.
Der obige Befehl sieht dann abgeändert wie folgt aus:
someval=$(/bin/dbclient -i /.ssh/serverx_rsa root@192.168.1.55 "df | grep Datastore" < /dev/ptyp7)
Die " " um den auszuführenden Befehl sind wichtig.
Das Pipen in anderen Befehle funktioniert aber nur zum Teil (u.a. wenn " verwendet werden).
Daher dann das ganze erst in der Ausgabe:
echo $someval | awk '{print $4 " " $6}' > /tmp/returnvalue
So funktionierts jetzt zumindest zum Teil (teste gerade nochmal alles). Falls ich das Skript im Ganzen zum laufen bekomme markiere ich den Beitrag hier als gelöst!
Pseudoterminals zum Teil lösen.
Der obige Befehl sieht dann abgeändert wie folgt aus:
someval=$(/bin/dbclient -i /.ssh/serverx_rsa root@192.168.1.55 "df | grep Datastore" < /dev/ptyp7)
Die " " um den auszuführenden Befehl sind wichtig.
Das Pipen in anderen Befehle funktioniert aber nur zum Teil (u.a. wenn " verwendet werden).
Daher dann das ganze erst in der Ausgabe:
echo $someval | awk '{print $4 " " $6}' > /tmp/returnvalue
So funktionierts jetzt zumindest zum Teil (teste gerade nochmal alles). Falls ich das Skript im Ganzen zum laufen bekomme markiere ich den Beitrag hier als gelöst!
Hi,
ich habe die letzten paar Tage zufälligerweise genau das gleiche Problem gehabt.
Und heute hab ich endlich die Lösung gefunden:
Ich wollte in etwa folgenden Befehl von crond ausführen lassen:
dbclient -T -i /.ssh/keys/work.db root@192.168.1.5 -R 4545:192.168.1.5:22
-T habe ich angegeben, damit explizit kein PTY zugewiesen wird.
Diese Zeile habe ich der einfachheithalber in ein Skript gepackt, inklusive einer Testzeile, damit ich später prüfen konnte, ob das Skript überhaupt von crond ausgeführt wird:
dbconn.sh
Dieses Skript starte ich manuell und lasse es im Hintergrund laufen mit:
(Falls unbekannt: nohup (No Hangup) stellt sicher, dass ein damit gestarteter Prozess beim z.B. ausloggen nicht beendet wird.)
Da das ganze manuell funktionierte, probierte ich als nächstes diesen Aufruf per crond automatisch starten zu lassen.
Crond führte dann auch auf jeden Fall das Skript aus, denn /tmp/test.txt wuchs in dem Intervall, das ich in der crontab definiert hatte, stetig an.
Doch dbclient wollte partout keine Verbindung zu 192.168.1.5 aufbauen und der Process beendete sich nach kurzer Zeit einfach!
Nach langem rumprobieren hab ich dann jedoch endlich des Rätsels Lösung gefunden:
Ein simples -N als weiterer Parameter... und alles läuft wie es soll.
D.h. das Skript lautet nun in seiner Finalversion so:
Laut http://linux.die.net/man/1/dbclient steht -N für:
Don't request a remote shell or run any commands. Any command arguments are ignored.
Ich habe bisher noch nicht probiert, ob das -T überflüssig macht. Ich war heute erstmal froh, dass ich's hinbekommen habe.
Hoffe das hilft dir und anderen, war wieder mal ein Problem wo selbst stundenlanges Googlen keine Früchte trug, sondern gutes altes Trial & Error.^^
Gruß und frohe kommende Ostern!
ich habe die letzten paar Tage zufälligerweise genau das gleiche Problem gehabt.
Und heute hab ich endlich die Lösung gefunden:
Ich wollte in etwa folgenden Befehl von crond ausführen lassen:
dbclient -T -i /.ssh/keys/work.db root@192.168.1.5 -R 4545:192.168.1.5:22
-T habe ich angegeben, damit explizit kein PTY zugewiesen wird.
Diese Zeile habe ich der einfachheithalber in ein Skript gepackt, inklusive einer Testzeile, damit ich später prüfen konnte, ob das Skript überhaupt von crond ausgeführt wird:
dbconn.sh
#!/bin/ash
echo test >> /tmp/test.txt
dbclient -T -i /.ssh/keys/work.db root@192.168.1.5 -R 4545:192.168.1.3:22Dieses Skript starte ich manuell und lasse es im Hintergrund laufen mit:
nohup /sbin/dbconn.sh &Da das ganze manuell funktionierte, probierte ich als nächstes diesen Aufruf per crond automatisch starten zu lassen.
Crond führte dann auch auf jeden Fall das Skript aus, denn /tmp/test.txt wuchs in dem Intervall, das ich in der crontab definiert hatte, stetig an.
Doch dbclient wollte partout keine Verbindung zu 192.168.1.5 aufbauen und der Process beendete sich nach kurzer Zeit einfach!
Nach langem rumprobieren hab ich dann jedoch endlich des Rätsels Lösung gefunden:
Ein simples -N als weiterer Parameter... und alles läuft wie es soll.
D.h. das Skript lautet nun in seiner Finalversion so:
#!/bin/ash
dbclient -T -N -i /.ssh/keys/work.db root@192.168.1.5 -R 4545:192.168.1.3:22Laut http://linux.die.net/man/1/dbclient steht -N für:
Don't request a remote shell or run any commands. Any command arguments are ignored.
Ich habe bisher noch nicht probiert, ob das -T überflüssig macht. Ich war heute erstmal froh, dass ich's hinbekommen habe.
Hoffe das hilft dir und anderen, war wieder mal ein Problem wo selbst stundenlanges Googlen keine Früchte trug, sondern gutes altes Trial & Error.^^
Gruß und frohe kommende Ostern!
