staging.inyokaproject.org

Marc_BlackJack_Rintsch schrieb:

@Emma2 Also ich entdecke da was: LIBVIRT_DEFAULT_URI=qemu:///system

Na ja, ich habe angenommen, dass das das Default ist.

Dennoch habe ich nun meine Crontab auf

1

30 * * * * /bin/virsh -d 0 connect qemu:///system && /bin/virsh -d 0 list --all &>> /home/localadmin/virshlistall.txt

geändert, aber die Datei bleibt noch immer leer, also auch keine Debugmeldungen kommen dort hinein.

Zum Vergleich, beim Aufruf direkt in der Bash erhalte ich

1
2

$ /bin/virsh -d 0 connect qemu:///system
connect: name(optdata): qemu:///system

@Emma2: Das ist nicht der Default, sondern man gibt damit den Default an.

Das connect macht doch in einem Cronjob gar keinen Sinn, weil man da ja gar nicht mit der Session interagieren kann.

Und werden die Kommandos in der Crontab eigentlich mit der Bash ausgeführt oder vielleicht mit der Dash? Denn &>> ist nicht Posix, vielleicht liegt es auch daran. Posix wäre … >>filename 2>&1

@Emma2 warum erstellst du kein Shell-Script, mit Angabe der Shell die du verwenden willst und mit der es dann auch klappt, und startest dann dieses als Cronjob? Also

#!/bin/bash
(...)

oder

#!/bin/sh
(...)

etc.

Problem scheint gelöst. Eure Tipps haben mich an der richtigen Stelle suchen lassen:

• virsh uri zeigt mir, dass in der Bash die Verbindung zu qemu:///system besteht, in der cron aber zu qemu:///session

• virsh connect hilft nicht, weil die Verbindung wohl nicht "persistent" ist

• virsh hat aber einen Parameter -c, den man jedem Aufruf mitgeben kann

• virsh -c qemu:///system list liefert auch aus der Crontab heraus das richtige Ergebnis

• Ich erweitere nun also alle Aufrufe von virsh in meinem Skripten mit diesem Parameter

Danke die Diskussion und eure Tipps!

Nachtrag:
Das Backup-Skript läuft jetzt und sichert die VM, das sieht also gut aus.

Nachtrag:
Der Versuch, die notwendige Umgebungsvariable innerhalb meines Skripts zu setzen, schlägt fehl, denn

1
2

LIBVIRT_DEFAULT_URI=qemu:///system
virsh list --all > virsh-list-all--log.txt

erzeugt wieder nur eine leere Datei. Ich muss also wohl das -c qemu:///system in jedem Aufruf mitschleppen.

@Emma2 Ohne export erzeugst Du nur eine Variable die in der aktuellen Shell existiert, aber nicht an die Umgebung von aus dieser Shell gestarteten Programme weitergegeben wird.

1
2

export LIBVIRT_DEFAULT_URI=qemu:///system
virsh list --all > virsh-list-all--log.txt

Ja, danke, das funzt auch.

Hier fehlen mir wohl noch Kenntnisse in der Shell-Programmierung: Ich habe angenommen, dass das Setzen einer Variablen innerhalb des Skripts selbst sehr wohl "persistent" wäre. Ist es aber wohl nur... "innerhalb des einen Befehls", also in der nächsten Zeile schon nicht mehr, oder wie muss ich das verstehen?

@Emma2 Eine Variable ist innerhalb des Skriptes sichtbar/bekannt in dem sie definiert wird, aber nicht in aus diesem Skript gestarteten Prozessen. Dazu muss man sie in die Umgebung exportieren Und das ist auch gut so, denn das käme schnell zu Chaos und ”Unfällen” wenn jedes Skript einfach so alle Variablen von vorhergehenden Skripten im Prozessbaum sehen könnte/müsste.

test1.sh:

1
2
3
4
5

#!/bin/sh
A=42
export B=23
echo "test 1 >$A< >$B<"
./test2.sh

test2.sh:

1
2

#!/bin/sh
echo "test 2 >$A< >$B<"

Testlauf:

$ ./test1.sh
test 1 >42< >23<
test 2 >< >23<

Das zweite Skript kann auf $B zugreifen, weil das vom ersten Skript in die Umgebung exportiert wurde und damit von Kindprozessen geerbt wird. $A dagegen ist nur innerhalb vom ersten Skript bekannt und kann dort benutzt werden.

Ok, danke, habe ich verstanden, ist also genauso (und genauso konsequent) wie lokale Variablen innerhalb einer Funktion oder eines Objektes und entsprechenden globalen Variablen.