Box hängt nach Shutdownbefehl in Skript! Hilfe?!

[quarkmark]

Hallo!

Habe mir erfolgreich mit Skripten ein Backup-System gebastelt, das die mit der einen Dbox aufgenommenen Filme nachts auf die andere Dbox überspielt. (Beide Boxen natürlich mit Festplatte.)

Leider gibt es da ein Problem.
Nach dem Kopieren soll sich die Aufnahme-Box wieder in den Deep-Standby schlafen legen. Nach einem Tipp hier im Forum (siehe http://forum.tuxbox-cvs.sourceforge.net ... 4&start=19 ) benutze ich dazu folgenden Befehl:
wget -Y off -q -O /dev/null http://127.0.0.1/control/shutdown
Leider hängt sich danach bzw. dabei die Box so auf, dass zwar Ton und Bild weiterlaufen, aber die Box nicht mehr bedienbar ist und nur noch über einen Reset zurückgesetzt werden kann (Ein/Aus + Pfeil oben).

Ich kann mir das nur so erklären, dass nach dem Kopieren der großen Datei (die übrigens immer einwandfrei kopiert wird!) die Box noch etwas Zeit braucht, um wieder ansprechbar zu sein, und dass der Shutdown-Befehl damit irgendwie in Konflikt kommt. (Ist aber nur so ne Vermutung, kenne mich damit wirklich nicht aus.) Ich habe testweise mal ein "sleep 20" vor dem Shutdown eingefügt, aber das brachte nichts.

Wer kennt sich hier aus und kann mir helfen?
Danke im Voraus,
beste Grüße,
qm

[palace]

20 Sekunden reichen nicht...

In der tat dauert es nach einem Transfer etwas...

Probier mal 40 - 60 Sekunden...

[quarkmark]

20 Sekunden reichen nicht...

In der tat dauert es nach einem Transfer etwas...

Probier mal 40 - 60 Sekunden...

Viel hilft viel....
Ich habe 300 Sekunden probiert.
Box hängt dann immer noch.
Was jetzt?
600 Sekunden?
Oder liegt es vielleicht an etwas anderem?
Muss vielleicht ein Prozess gekillt werden, der den shutdown verhindert? (Habe aber sonst nichts Besonderes laufen.)
Hilfe?!
Gruß,
qm

[quarkmark]

Spontane Idee:
Kann man nicht vor dem Shutdown einfach im Skript alle Prozesse killen, die nicht mehr benötigt werden? Das dürften alle sein, außer der Prozess, der den Timer im Frontprozessor setzt, um die Box beim nächsten programmierten Event wieder aufzuwecken. Welcher ist das, den man dann nicht killen darf? Und wie killt man sicher alle anderen Prozesse?
Ist nur so ne Idee.
Mensch, das muss doch Hinzukriegen sein. Bin ich denn der Einzige, der das so versucht? Kann das nicht auch mal jemand von Euch ausprobieren?
Beste Grüße,
qm

[zexma]

*Glaskugelkaputt*
die annahmen und vermutungen "erklärungen" und "spontane ideen" mögen zum zeitvertreib ja ganz nett sein ...
ich würde mir da eher das log anschauen ...

[quarkmark]

*Glaskugelkaputt*
die annahmen und vermutungen "erklärungen" und "spontane ideen" mögen zum zeitvertreib ja ganz nett sein ...
ich würde mir da eher das log anschauen ...

Ja, klar, aber das ist nicht ganz so einfach, da die Dbox im Wohnzimmer steht und kein PC in direkter Reichweite.
Also bitte weiter Glaskugel bemühen
Nee, im Ernst, was macht denn der shutdown-Befehl überhaupt?
Was kann denn da hängenbleiben
Gruß,
qm

[Papst]

Also grundsätzlich sollte man Neutrino vielleicht mal beibringen das TERM Signal zu verarbeiten und sich ordentlich zu beenden. Dann könnte man die Box auch mit einem kill -TERM $(pidof neutrino) sauber runterfahren.

[quarkmark]

Habe 6000 Sekunden probiert. Ohne Erfolg.
Wie gesagt: Die Dateien werden ohne Probleme kopiert, der einzige Befehl, der dann noch abgearbeitet wird, ist der shutdown-Befehl. Und dann hängt die Box.
Hilfe?!
Gruß,
qm

[DrStoned]

Wie wäre es mal mit einem kompletten Listing Deines Skripts und einem seriellen Log der Box? Sonst grenzt die ganze Fehlersuche an Kaffeesatzleserei.

Greetz von DrStoned

[Heavendenied]

Also wie dir andere auch schon gesagt haben ist ein LOG nunmal schon wichtig bei der Fehlersuche. Also musst du entweder mal die Box neben den PC stellen oder halt mit nem Laptop oder so zur D-Box nin gehen und das Log machen.

Hast du mal versucht die Box einfach nur runter zu fahren? Also nur den Befehl den du zum runterfahren nimmst einzeln in ein Skript zu packen und auszuführen? Dann wüsstest du obs wirklich an dem Befehl liegt.
Da du in dem anderen thread ja die Vermutung angestellt hast, es könnte am IDE-IF liegen, bau es doch einfach mal aus und probiers dann nochmal(natürlich nur das runterfahren, kopieren kannste ja dann nix mehr).

[Gorcon]

Habe 6000 Sekunden probiert. Ohne Erfolg.
Wie gesagt: Die Dateien werden ohne Probleme kopiert, der einzige Befehl, der dann noch abgearbeitet wird, ist der shutdown-Befehl. Und dann hängt die Box.
Hilfe?!
Gruß,
qm

Welche Box hast Du denn genau? mit einer Nokia zB. gabs bei Shutdown immer schon probleme wenn nicht vorher einige Prozesse geschlossen werden.

Ich wäre übrigens auch an dem Script interessiert.
Mich würde mal intteressieren wie die Box runterfährt. Wird das Zeitgesteuert oder erst wenn das kopieren (verschieben) wirklich beendet ist?
Was passiert wenn dann ein Aufnahmetimer dazwischen kommt?

Gruß Gorcon

[quarkmark]

Also, nochmal:
Das runterfahren der Box mittels folgendem Befehl funktioniert allein für sich einwandfrei! Der Befehl lautet:
wget -Y off -q -O /dev/null http://127.0.0.1/control/shutdown
Dieser Befehl funktioniert auch innerhalb eines Skriptes einwandfrei zum Herunterfahren der Box.
ABER: Wenn die Box per Umschalttimer geweckt wurde, dann per Skript eine riesige Film-Datei kopiert wurde, dann bleibt die Box hängen, wenn danach der Shutdown-befehl ausgeführt wird. (Bild und Ton laufen, Box ist nicht mehr bedienbar, Hardware-Reset ist nötig.)
Die Datei wird jeweils vorher einwandfrei kopiert, nur eben der Shutdown-Befehl wird nicht richtig ausgeführt.
Das Skript lautet so:

#!/bin/sh
# Festplatte der anderen Box aufwecken
ls /mnt/filme > /dev/null
sleep 15
# Filme kopieren und dann löschen, andere Festplatte ist nach /mnt/filme/filme gemountet per mount-Menü und ftpfs.
cp /hdd/filme *.xml /mnt/filme/filme
cp /hdd/filme *.ts /mnt/filme/filme
rm /hdd/filme *.xml
rm /hdd/filme *.ts
# An dieser Stelle noch ein Sleep einzufügen, hat nichts bewirkt, nicht mal mit 6000 Sekunden!
wget -Y off -q -O /dev/null http://127.0.0.1/control/shutdown

Bevor Ihr jetzt meckert: Ich habe natürlich auch den befehl mv probiert, aber aus einem mir nicht ersichtlichen Grund dauert dann das Kopieren viel viel länger als mit kopieren und dann löschen!

Im Moment mache ich es wieder so, dass die Aufnahme-Box immer nur im einfachen Standby ist (nicht Deep-Standby), und dass dann der Shutdown-Befehl auskommentiert ist. Dann bleibt die Box nach dem Kopieren bedienbar. Zwar muss man etwas warten, aber dann ist alles in Ordnung.
Aber ich würde natürlich gerne den Deep-Standby nutzen.

Ach ja, Aufnahme-Box ist eine Nokia Avia500, die andere ist eine Sagem. Andere Hänger oder Probleme habe ich mit den Boxen üblicherweise nicht. Ich benutze den aktuellen JTG-Snap vom 9.10.06.

Und nein, ich kann immer noch nicht mit einem Log dienen, habe im Moment absolut keine Zeit, Computer hin und her zu tragen, sorry.

Beste Grüße,
qm

[palace]

Ein "bisschen" Log bekommst Du auch mit "dmesg" an der Konsole.

bsp:

dmesg > /hdd/kernellog.txt

[quarkmark]

Ein "bisschen" Log bekommst Du auch mit "dmesg" an der Konsole.

bsp:

dmesg > /hdd/kernellog.txt

ich habe mal Dein Beispiel übernommen.
Problem ist nur, dass vor dem Shutdown-Befehl natürlich nichts über das Problem ausgegeben werden kann, und nach dem Shutdown-Befehl hängt die Box soweit, dass auch dmesg nicht mehr ausgeführt wird.
Mist.
Ich glaube, es hilft nur was, wenn mal einer von Euch wirklichen Könnern das mal selbst ausprobiert und ein "richtiges" Log macht.
Bis dahin läuft meine Aufnahmebox eben immer im Standby und nicht im Deep-Standby.
Also, wer was Neues herausfindet, hier posten.
Danke und Grüße,
qm

[Gorcon]

Ich tippe mal darauf das die Box nicht runterfährt weil sie noch eine Verbindung zur anderen Box hat.
Unmounte die HDD mal bevor Du sie runterfährst.

Gruß Gorcon

[quarkmark]

Ich tippe mal darauf das die Box nicht runterfährt weil sie noch eine Verbindung zur anderen Box hat.
Unmounte die HDD mal bevor Du sie runterfährst.

Gruß Gorcon

Also nochmal ganz klar:
Ich habe natürlich mal zum Test eine Minute aufgenommen und danach das Skript gestartet. Ergebnis: Die Datei wird kopiert und die Box heruntergefahren. Alles toll.
Wenn aber das Skript timergesteuert gestartet wird und eine RIESENDATEI von 3 GB kopiert wird, dann findet der Shutdown nicht statt und die Box hängt stattdessen.
Ich weiß, es ist widersinnig, aber leider ist es so.
Aber gut, ich probier das Unmounten mal. Obwohl: Was hat das Unmounten mit der Verbindung zur anderen Box zu tun?

Wie wäre es, wenn Du das mal probierst, ob das Skript (oder ein ähnliches) bei Dir funktioniert?
Gruß,
qm

[Gorcon]

Leider nutzt mir das Script so nichts. Ich dachte es wäre dafür gedacht um die Daten auf einen PC zu übertragen.

Ich könnte die Daten zwar auf meine andere Box auf der ich eine NFS HDD drin habe, kopieren nur was nutzen mir die Daten dort wenn ich sie dann immernoch nicht auf dem PC habe?

Ich hatte dort aber einen ähnlichen Effekt schon gehabt. Ich wollte dort per Tuxcommander ein paar Filme auf die IDE Interface Box kopieren und dann per Sleeptimer die Box dann runterfahren lassen. (Die Zeit hatte ich dort reichlich bemessen). Die Boxen liefen nächsten Tag noch immer.

Da das Auslesen der HDD direkt unter Vista nicht möglich ist bin ich auf eine andere Lösung angewiesen.

Gruß Gorcon

[quarkmark]

Leider nutzt mir das Script so nichts. Ich dachte es wäre dafür gedacht um die Daten auf einen PC zu übertragen.
Gruß Gorcon

Letztendlich ist es scheinbar doch (fast) wurscht, wohin die Daten gehen.
Anscheinend ist es ja auch nach Deinen Erfahrungen folgendermaßen:

Wenn große Dateien von der Festplatte einer Box per Netzwerkkabel woanders hin übertragen werden, dann kann man die Box danach nicht per Skript oder Timer in den Deep-Standby herunterfahren.

Das ist die "offizielle" Fehlerbeschreibung bisher, jedenfalls meiner Meinung nach.

Was sagen denn die Image-Experten dazu? Oder Gurgel und dboxbaer?
Vielleicht können wir "Normalsterbliche" gar keine Lösung dafür finden?

Gruß,
qm

[Gorcon]

Letztendlich ist es scheinbar doch (fast) wurscht, wohin die Daten gehen.

Jaein. Nicht wenn sie auf den PC per FTP übertragen werden.
Einen NFS Server habe ich momentan auf dem PC nicht installiert. (bisher noch nie einen Bedarf gesehen).

Gruß Gorcon

[quarkmark]

Letztendlich ist es scheinbar doch (fast) wurscht, wohin die Daten gehen.

Jaein. Nicht wenn sie auf den PC per FTP übertragen werden.
Einen NFS Server habe ich momentan auf dem PC nicht installiert. (bisher noch nie einen Bedarf gesehen).

Gruß Gorcon

Verstehe ich nicht, aber egal.

Also, ich nehme meine fettgedruckte Fehlerbeschreibung oben als gegeben an, solange es niemand besser schafft (worüber ich mich freuen würde)!
Gruß,
qm

[Gorcon]

Ich wollte damit sagen das Dein Script nicht dafür taugt um Daten auf den PC zu überspielen auf dem kein NFS Server läuft. (was jetzt aber keine Kretik sein soll)

Gruß Gorcon

[quarkmark]

Ich wollte damit sagen das Dein Script nicht dafür taugt um Daten auf den PC zu überspielen auf dem kein NFS Server läuft. (was jetzt aber keine Kretik sein soll)

Gruß Gorcon

Klar, kein Problem. Aber was ich meinte war das:
Zitatvon mir:
Letztendlich ist es scheinbar doch (fast) wurscht, wohin die Daten gehen.
Antwort von Dir:
Jaein. Nicht wenn sie auf den PC per FTP übertragen werden.

Aus meiner Sicht ist es wurscht, wohin die Daten gehen. Die Box kann man danach nicht per Skript oder Timer in den Deep-Standby bringen.

Ich lasse mich aber gerne eines Besseren belehren!
Vielleicht schaffts ja doch jemand.
Gruß,
qm