umount: Couldn't umount /var: Inappropriate ioctl for device

wolgade
Semiprofi
Semiprofi
Beiträge: 1313
Registriert: Donnerstag 2. Dezember 2004, 00:18

Beitrag von wolgade »

Ich muß an einer Stelle zurückrudern. Meine Aussage, daß

Code: Alles auswählen

[yhttpd] stop requested...... 
darauf schließen läßt, daß "start_neutrino" noch läuft, ist falsch. yhttpd wird nicht in "start_neutrino" beendet. yhttpd wird nirgends beendet. Ich hab auch nicht gefunden, wann yhttpd gestartet wird. Auch mit ps ist das Biest nicht sichtbar.

/etc/init.d/halt sieht jetzt so aus:

Code: Alles auswählen

#!/bin/sh

# $Id: halt,v 1.4 2006/09/28 18:28:06 barf Exp $
ps -aux
sleep 10

mount | grep /hdd >/dev/null && umount /hdd

[ -e /var/run/automount.pid ] && kill -TERM $( cat /var/run/automount.pid )
[ -e /tmp/tuxmaild.pid ] && kill $( cat /tmp/tuxmaild.pid )
[ -e /tmp/tuxcald.pid ] && kill $( cat /tmp/tuxcald.pid )

switch -fnc 0 -fblk 0

mount -v -n -o remount,ro jffs2 /var
umount /var
sleep 10
Wie man sieht, habe ich zweimal einen Mittagsschlaf von 10 Sekunden eingebaut. Zusätzlich will ich wissen, welche Prozesse beim Start von "halt" noch aktiv sind.

Das Bootlog ist aufschlußreich:

Code: Alles auswählen

zapit shot down :)
Waiting for controld (max. 9 seconds)
[sectionsd] getUTC: read: Connection timed out
Starting pid 184, console /dev/console: '/etc/init.d/halt'
  PID  Uid     VmSize Stat Command
    1 root        472 S   init
    2 root            SW  [keventd]
    3 root            SWN [ksoftirqd_CPU0]
    4 root            SW  [kswapd]
    5 root            SW  [bdflush]
    6 root            SW  [kupdated]
    7 root            SW  [mtdblockd]
   27 root            SWN [jffs2_gcd_mtd3]
   94 root        600 S   /sbin/inetd
  120 root        676 S   -sh
  121 root        472 S   init
  122 root        472 S   init
  125 root        472 S   init
  126 root        472 S   init
  127 root        472 S   init
  136 root       1280 S   sectionsd
  137 root       1280 S   sectionsd
  138 root       1280 S   sectionsd
  139 root       1280 S   sectionsd
  140 root       1280 S   sectionsd
  142 root       1280 S   sectionsd
  143 root       1280 S   sectionsd
  144 root       1280 S   sectionsd
  147 root        404 S   camd2
  158 root       1688 S   nhttpd
  183 root        476 S   init
  184 root        508 S   /bin/sh /etc/init.d/halt
  185 root        612 R   ps -aux
CXA2092 found
umount: Couldn't umount /var: Inappropriate ioctl for device
The system is going down NOW !!
Sending SIGTERM to all processe[yhttpd] stop requested......
Sending SIGKILL to all processes.
Requesting system halt.
Was sagt uns das?

Zu dem Zeitpunkt, wo "halt" losspurtet, ist noch allerhand los. sectionsd, nhttpd und camd2 sollten mausetot sein.

Was ich nicht kapiere: Jetzt plötzlich wird vor SIGKILL noch SIGTERM gesendet. Das ist gut und vernünftig. Wieso aber hängt das an Sleep-Anweisungen in "halt"?
T-Nec
Einsteiger
Einsteiger
Beiträge: 207
Registriert: Montag 9. Januar 2006, 13:54

Beitrag von T-Nec »

hmmm
Was ich komisch finde: daß bei dir das Image immer den "Arsch hoch" macht...
Mein var macht genau den selben Fehler und lässt sich nicht unmounten wird aber nicht zerstört (bisher).

Ich benutzte im Moment eine SD-Kartenpartition als /var ... (ext2)
wolgade
Semiprofi
Semiprofi
Beiträge: 1313
Registriert: Donnerstag 2. Dezember 2004, 00:18

Beitrag von wolgade »

Unmounten scheint nirgends zu klappen. Remount read-only klappt allerdings meistens.

Was da wirklich die Hufe reißt, weiß ich nicht. Auf jeden Fall wird die Box nicht sauber runtergefahren. Damit muß mein Problem zusammenhängen. Mal kann ich die Box dreimal neu starten, bevor der Ofen aus ist, mal klappt das nur zweimal. Es kann eigentlich nur mit /var zu tun haben. Root ist nicht beschreibbar und damit eigentlich unkaputtbar und /tmp verliert sein Gedächtnis, wenn der Strom abgestellt wird. Da bleibt nicht viel. Wenn das JtG-Image nicht liefe, würde ich vermuten, daß der Flashspeicher kaputt ist. Um ehrlich zu sein: Hardwaredefekt war meine erste Vermutung, nachdem erstmalig das Problem mit der Ladeschleife auftrat.
KaLiBo
Neugieriger
Neugieriger
Beiträge: 9
Registriert: Sonntag 8. Oktober 2006, 00:34

Beitrag von KaLiBo »

Hi,

ich spreche mal von enigma. Meine Testumgebung ist aber vorerst noch provisorisch. Das meiste passiert ausserhalb enigmas, also in den üblichen Scripts.

Wenn ich mich im Filemodus befinde, scheint es irgendwie unmöglich die hdd auszuhängen. Wechsle ich zurück in den TV/Radiomodus, dann geht was.

Wenn ich ein manuell erstelltes Swapfile laufen habe, kann ich nicht die hdd aushängen.

Wenn ich zuvor swapoff /hdd/swapfile eingebe (vorrausgesetzt es gibt /hdd/swapfile, und swapon /hdd/swapfile war zuvor aktiv), kann ich mit umount /hdd die Platte aushängen. Anmerkung: Enigma erstellt auch unter der Dream nur eine Partition, und der Swap ist ein File, statt eine weitere Partition. Also isses (ohne weiteres dazucoden) bei der Dbox2 erstmal auch so.

Wenn ich vor dem runterfahren keinen Kerneltreiber wieder aus dem Speicher lösche (rmmod), bekomme ich nach SIGTERM/SIGKILL von "halt" noch die Meldung "flushing ide devices: hda", aber Box+hdd schalten exakt in dem Moment den Strom ab. Er kann dann wohl nicht mehr "flushen" (was es da auch immer noch wichtiges zu flushen gibt). Dies führt evtl. zu defekten Stellen im Filesystem, und der Flush-Prozess lässt sich auch scheinbar mit keinem Trick vor-ziehen. Eigentlich verständlich, wenn man bedenkt, dass das ganze IDE-IF-Konstrukt auf einem RAM-Erweiterungs-Slot steckt. Der RAM bekommt immer am Ende seinen Strom abgeklemmt; warum auch nicht? Ich glaube, ich habe den internen hdd-Cache mittels hdparm noch nicht aus. Evtl. verhält es sich dann anders. Die "nicht mehr ausreden könnende" Flush-Info kommt übrigens aus ide-core.o

Wenn ich versuche (swapoff, und umount sind schon durch), nun mit "rmmod ide-core" zu tricksen, damit es ein sauberer Shutdown wird, gibts Haue, weil der ja noch aktiv ist.

Wenn ich die Platte mit "hdparm -Y /dev/ide/host0/bus0/target0/lun0/part1" quasi ausschalte, dann kann ich (in der Reihenfolge, unter Telnet) mit rmmod ide-disk, rmmod ide-detect, rmmod dboxide und dann zuletzt den Kampf aufgebenden rmmod ide-core erfolgreich sämtlichen IDE-Stuff auslöschen. Danach ein "halt" (also der Befehl halt, kein Script), und es wird alles ohne Meckereien beendet. Und ab damit, in die Scripts -->Löppt!

Das war aber ein REIN manueller Test. Vieles ist ja in enigma schon drin; das hab ich jetzt alles (noch) nicht genutzt. In diesem manuellen Test habe ich die fstab völlig unangetastet, ausser tmpfs statt ramfs. Und alle Kernel-Treiber werden in rcS.local geladen, mit einem abschliessenden mount für die hdd. Der Shutdown-Vorgang mit swapoff, umount und den rmmods steht in start_enigma, vor dem /sbin/halt

Soweit meine ersten, provisorischen Gehversuche. Vielleicht ist ja irgendwas brauchbares für den armen, verzweifelten wolgade dabei.

Gruss, K
wolgade
Semiprofi
Semiprofi
Beiträge: 1313
Registriert: Donnerstag 2. Dezember 2004, 00:18

Beitrag von wolgade »

Vielleicht ist ja irgendwas brauchbares für den armen, verzweifelten wolgade dabei.
Danke für das Mitgefühl, aber ich seh das inzwischen sportlich. Ich will jetzt keinen Workaround mehr, ich will jetzt den Shutdown verstehen. Und da bin ich durch dich einen Schritt weiter.
Danach ein "halt" (also der Befehl halt, kein Script)
Argh, natürlich. In "start_neutrino" wird "halt" aufgerufen. Das dürfte wohl /sbin/halt sein, es sei denn, /etc/init.d ist im Pfad. /sbin/halt seinerseits ruft /etc/init.d/halt auf. Richtig?

Ich hab mir mal /etc/init.d/halt von Jtg angeguckt. Da werden wesentlich mehr Aufräumarbeiten gemacht, vor allem aber ein sync vor dem Aushängen der Dateisysteme. Muß ich mir mal in Ruhe ansehen, allerdings weder heute noch morgen. Es gibt noch andere Dinge im Leben als die D-Box.
Muttersöhnchen
Interessierter
Interessierter
Beiträge: 73
Registriert: Samstag 31. Juli 2004, 18:15

Beitrag von Muttersöhnchen »

KaLiBo hat geschrieben:Wenn ich mich im Filemodus befinde, scheint es irgendwie unmöglich die hdd auszuhängen. Wechsle ich zurück in den TV/Radiomodus, dann geht was.
Solange ein Gerät in use ist, solange geht kein umont.
Beispiel:
cd /var/
/var > umount /var
umount: Couldn't umount /var: Inappropriate ioctl for device
/var > cd /
umount /var
Du kannst mit lsof finden, was noch /var blockiert.
Am besten vor umont /var das schreiben lsof +D /var/

ps. lsof ist in cvs.
KaLiBo
Neugieriger
Neugieriger
Beiträge: 9
Registriert: Sonntag 8. Oktober 2006, 00:34

Beitrag von KaLiBo »

Muttersöhnchen hat geschrieben: Solange ein Gerät in use ist, solange geht kein umont.
jep
hannebamb(el)
Foren-Moderator
Beiträge: 297
Registriert: Montag 11. Oktober 2004, 14:51

Beitrag von hannebamb(el) »

Muttersöhnchen hat geschrieben: Du kannst mit lsof finden, was noch /var blockiert.
Am besten vor umont /var das schreiben lsof +D /var/

ps. lsof ist in cvs.
Kannst du dann noch mit kill kombinieren, z.B. in /etc/init.d/halt:
kill -15 `lsof -t /var`
sleep 1
kill -9 `lsof -t /var`