[0.2] Shutdown: force-fsck versucht fsck auf eingehängtem Dateisystem!

dron72 · 5. September 2010

Hallo zusammen,

mein yavdr bleibt gelegentlich beim Shutdown hängen - inzwischen weiss ich auch wieso.
Er versucht ein fsck auf meiner (wohl noch eingehängten) Datenplatte - und wartet auf die Antwort auf die Frage "Willst Du wirklich fsck durchführen, auch wenn Du bei nem eingehängten Dateisystem Daten schrottest?"

Die Ursache scheint mir aber einen Schritt vorher zu liegen:

und zwar beim Aufruf von "umountfs stop" beim Shutdown.

Code

* Will now unmount local filesystems
Konnte /net.yavdr nicht in „mtab“ finden
umount2: Device or resource busy
umount: /net.yavdr wird momentan noch benutzt – im Nur-Lese-Modus wiedereingehängt
Segmentation fault
   ...fail!

und wenn ichs recht im Kopf habe, gibts anschliessend noch einen Segmentation fault beim "touch /etc/mtab" in dem Script. [EDIT: kein Segmentation fault, sondern touch nicht möglich, da / ja als read-only gemounted wurde...] Wenn ich manuell ausführe funktioniert alles (er erkennt, dass die Partition noch gemounted ist und macht nichts). Habe Details hierzu aber bisher nicht in den logs gefunden? Wird das überhaupt irgendwo hingeloggt und wenn ja, wo?

Jemand ne Idee? Die Datenplatte sollte eben sauber umounted werden, bevor force-fsck ans Werk geht.

Hier noch meine /etc/fstab

Code

# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    nodev,noexec,nosuid 0       0
# / was on /dev/sdd1 during installation
UUID=5117b712-d3c0-4833-8e06-a2f027ec5f1e /               ext3    errors=remount-ro 0       1
# swap was on /dev/sdd2 during installation
UUID=b833eb26-1845-4136-bdd9-4c3dfc2e1bbc none            swap    sw              0       0
UUID=4f7d02c7-f049-4e17-934b-09d9bbc76e5e       /srv/data       ext4    defaults        0       2

Wenn Ihr noch weiter Infos braucht...

Danke,

Olli

Dirch · 5. September 2010

Füge mal in /etc/init/onshutdown.conf vor dem "end script" die Zeile umount -l /srv/data ein. Wenn es funktioniert musst du es noch tempelaten.

Ist quick and dirty - es gibt bestimmt noch eine schönere Lösung dafür.

dron72 · 5. September 2010

Danke für die Antwort. Ich werde das mal testen, aber ich befürchte, dass das Problem mit der Root-Partition genauso auftreten wird.
Das umount script kann nicht umounten, da /net.yavdr (was ist das eigentlich) noch benutzt wird. mounted daher das Root Dateisystem als Read-Only, dann gibts die Folgefehler, dass ein touch /etc/mtab nicht möglich ist....

Da ich in dem Bereich nix gefummelt habe, sollte das Problem doch bei einigen von Euch bestehen...

Habe mal (mangels logs) einen Screenshot (im wahrsten Sinne des Wortes ) angehängt...

BTW: Max mount Count -1 habe ich bewusst gesetzt, zum Testen. Sollte keine Auswirkung haben.

Dirch · 5. September 2010

Bringt es nichts, wenn du auf oben beschriebenem Weg mit umount -l /net.yavdr die Sache regelst ?

dron72 · 5. September 2010

Nein, denn das Verzeichnis ist nicht gemounted, sondern einfach ein (leeres) Verzeichnis in der Root Partition...

Wahrscheinlich hat irgendwer (vdr?!) das Verzeichnis noch in der Hand, wenn das umount Skript läuft...
Hier noch ein paar Infos:

Code

olli@htpc:/$ ls -l /
insgesamt 88
drwxr-xr-x   2 root root  4096 2010-08-31 22:46 bin
drwxr-xr-x   3 root root  4096 2010-09-02 09:25 boot
drwxr-xr-x   2 root root  4096 2010-08-22 23:10 cdrom
drwxr-xr-x  18 root root  3940 2010-09-05 20:09 dev
drwxr-xr-x 100 root root  4096 2010-09-05 20:08 etc
drwxr-xr-x   3 root root  4096 2010-08-22 23:19 home
lrwxrwxrwx   1 root root    33 2010-08-22 23:25 initrd.img -> boot/initrd.img-2.6.32-24-generic
lrwxrwxrwx   1 root root    33 2010-08-22 23:10 initrd.img.old -> boot/initrd.img-2.6.32-22-generic
drwxr-xr-x  18 root root 12288 2010-09-02 09:24 lib
drwx------   2 root root 16384 2010-08-22 23:08 lost+found
drwxr-xr-x   2 root root  4096 2010-08-31 21:58 media
drwxr-xr-x   5 root root  4096 2010-09-01 21:54 mnt
drwxr-xr-x   2 root root     0 2010-09-05 20:09 net.yavdr
drwxr-xr-x   2 root root  4096 2010-08-22 23:09 opt
dr-xr-xr-x 142 root root     0 2010-09-05 20:08 proc
drwx------   5 root root  4096 2010-08-29 10:13 root
drwxr-xr-x   2 root root  4096 2010-09-02 09:24 sbin
drwxr-xr-x   2 root root  4096 2009-12-05 22:55 selinux
drwxr-xr-x   4 root root  4096 2010-09-01 21:24 srv
drwxr-xr-x  12 root root     0 2010-09-05 20:08 sys
drwxrwxrwt   4 root root  4096 2010-09-05 20:09 tmp
drwxr-xr-x  12 root root  4096 2010-08-31 22:46 usr
drwxr-xr-x  14 root root  4096 2010-08-23 01:05 var
lrwxrwxrwx   1 root root    30 2010-08-22 23:25 vmlinuz -> boot/vmlinuz-2.6.32-24-generic
lrwxrwxrwx   1 root root    30 2010-08-22 23:10 vmlinuz.old -> boot/vmlinuz-2.6.32-22-generic

Alles anzeigen

Was ist in dem "Problem"-Verzeichnis?

Code

olli@htpc:/$ ls -lR /net.yavdr/
/net.yavdr/:
insgesamt 0
olli@htpc:/$

nichts...

Welche Dateisysteme sind aktuell gemounted?

Code

olli@htpc:/$ mount
/dev/sdb1 on / type ext3 (rw,errors=remount-ro)
proc on /proc type proc (rw,noexec,nosuid,nodev)
none on /sys type sysfs (rw,noexec,nosuid,nodev)
none on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
none on /dev type devtmpfs (rw,mode=0755)
none on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
none on /dev/shm type tmpfs (rw,nosuid,nodev)
none on /var/run type tmpfs (rw,nosuid,mode=0755)
none on /var/lock type tmpfs (rw,noexec,nosuid,nodev)
none on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
/dev/sdc1 on /srv/data type ext4 (rw)
rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
nfsd on /proc/fs/nfsd type nfsd (rw)
olli@htpc:/$

Alles anzeigen

und eben das gleiche Ergebnis (oh Wunder..)

Code

olli@htpc:/$ cat /etc/mtab
/dev/sdb1 / ext3 rw,errors=remount-ro 0 0
proc /proc proc rw,noexec,nosuid,nodev 0 0
none /sys sysfs rw,noexec,nosuid,nodev 0 0
none /sys/fs/fuse/connections fusectl rw 0 0
none /sys/kernel/debug debugfs rw 0 0
none /sys/kernel/security securityfs rw 0 0
none /dev devtmpfs rw,mode=0755 0 0
none /dev/pts devpts rw,noexec,nosuid,gid=5,mode=0620 0 0
none /dev/shm tmpfs rw,nosuid,nodev 0 0
none /var/run tmpfs rw,nosuid,mode=0755 0 0
none /var/lock tmpfs rw,noexec,nosuid,nodev 0 0
none /lib/init/rw tmpfs rw,nosuid,mode=0755 0 0
/dev/sdc1 /srv/data ext4 rw 0 0
rpc_pipefs /var/lib/nfs/rpc_pipefs rpc_pipefs rw 0 0
nfsd /proc/fs/nfsd nfsd rw 0 0
olli@htpc:/$

Alles anzeigen

Vielleicht gibts ja weitere Ideen...

Werde mal ein umount -l / nach Deinem Weg versuchen - aber der wird genauso scheitert, befürchte ich, da net.yavdr ja im Zugriff zu sein scheint... Vielleicht hilft das "-l" ja was - hatte das bisher noch nie verwendet...

Dirch · 6. September 2010

fuser -mvu /net.yavdr und/oder lsof /net.yavdr verraten dir mehr. Automount scheint hier der Schuldige zu sein. "stop autofs" dürfte aber hier die Lösung sein.

Wenn du "-l" anwendest ist es nicht notwendig, ist aber auch die hardcore Variante dessen Anwendung eigentlich auch nicht empfohlen wird.

Mir ist noch kein Fall untergekommen in dem "-l" versagt hat, aber das hat schon fast was von "mittendrinn den Stecker ziehen" - sauber ist anders.

dron72 · 6. September 2010

Hi, nochmal danke - ist ja quasi Individualbetreuung hier

Habe heute morgen auch schon selbst den Schuldigen identifiziert, kam nur noch nicht dazu, das zu posten.

Code

root@htpc:/etc/rc0.d# fuser -v /net.yavdr/
                     BEN.        PID ZUGR.  BEFEHL
 /net.yavdr/:         root     kernel mount /net.yavdr                     
root       1583 f.... automount 
root@htpc:/etc/rc0.d# ps awx | grep 1583
  1583 ?        Ssl    0:00 /usr/sbin/automount
  1893 pts/0    S+     0:00 grep --color=auto 1583

Das "stop autofs" ist ein super Tipp, sonst hätte ich heute Abend (wenn ich wieder an der Kiste sitze) danach gesucht. Werde mal schauen, dass ich das in den Shutdown vor die umount, umount-rootfs (aus dem Kopf...) und force-fsck Scripte reinhänge.

Werde berichten!

dron72 · 7. September 2010

Das stop autofs hat bisher geholfen. Habs einfach mal in den stop Zweig des umountfs eingebaut. Dennoch irritiert mich in dem Script das "touch /etc/mtab" wenn das root fs vorher read-only gemounted wird.

Naja, wie auch immer. Scheint jetzt auf jeden Fall zu funktionieren - und er macht brav seinen fsck wenn nötig. Sowohl auf der Root, als auch auf der Datenpartition...

...aber hat denn niemand mit dem yavdr 0.2 das gleiche Problem? Wundert mich ein wenig, da ich hier einen absoluten Standard yavdr0.2 ohne gebastel (außer dem gerade oben erwähnten) habe...

steffen_b · 7. September 2010

Moin !

Werden auch andere haben. Ich vermute das die meisten es nicht soweit identifiziert haben und die Ursache zurückverfolgt.

dron72 · 7. September 2010

steffen_b: Vielen Dank! Dann kann man ja vielleicht auf eine "offizielle" Lösung hoffen. Für mich funktionierts so aber.

Ich werde noch schauen, dass ich das sauberer hinbekomme, also ein eigenes (mini) Script zum stop autofs vor den umountfs zu hängen oder das umountfs entsprechend zu templaten -> Muss mich da mal etwas einlesen, habs bisher nur überflogen und das Konzept dahinter verstanden...

Wenn ich da noch etwas beisteuern/testen/infos liefern etc. kann, gebt ruhig Bescheid.

utiltiy · 7. September 2010

Zitat

Original von dron72
steffen_b: Vielen Dank! Dann kann man ja vielleicht auf eine "offizielle" Lösung hoffen

Für 0.3 wird es eine Änderung dazu geben wenn man das SVN verfolgt

dron72 · 7. September 2010

Guter Hinweis. Vielen Dank. Sind ja gestern einige Commits rund um das Thema im SVN... Hatte da bisher auch noch nicht reingeschaut; bin recht neu beim yavdr.

Innocenti73 · 8. September 2010

Kann den Fehler bestätigen, hatte nur bisher keine Zeit das weiter zu verfolgen und hätte ich auch nicht so schnell mit autofs in Verbindung gebracht ohne über den thread hier zu stolpern.

Mir ist eigentlich nur aufgefallen dass mein fsck immer beim System-Start lief anstatt beim shutdown, eine Nachfrage den Check auf dem gemounteten FS zu machen habe ich noch nicht bekommen.
Hatte mal per tune2fs manuell gesetzt und per shell einen reboot gemacht, da kam auch ein Fehler, der aber zu schnell weg war um etwas lesen zu können, in den logs war nichts zu finden. Denke auch das die meisten das garnicht merken werden.

dron72: In /etc/init.d/umountfs hast Du jetzt stop autofs eingetragen? Welche Zeile?

Dirch · 8. September 2010

Zitat

Original von Innocenti73
Kann den Fehler bestätigen, hatte nur bisher keine Zeit das weiter zu verfolgen und hätte ich auch nicht so schnell mit autofs in Verbindung gebracht ohne über den thread hier zu stolpern.

Es muß auch nicht autofs sein, meine Systempartition ist xfs formatiert, da ist das völlig schnuppe, da der Festplattencheck in dem Fall den Shutdown eh nicht blockieren kann. Leider ist meine eingehängte Video Partition noch ext3 und neigte dazu den Shutdown nicht komplett durchlaufen zu lassen. Das sollte man je nach Konfiguration ebenfalls in Betracht ziehen, da hier ein stop autofs herzlich wenig bringt.

Man kann die Frage nach dem Check der gemounteten Partition aber mit einem Strg-Alt-F9 und einem Druck auf y oder n auch blind ausführen - ich fand es für mich nur bequemer mit dem umount -l.

Gruß Dirch

dron72 · 8. September 2010

Habs in den "stop-Zweig" meiner /etc/init.d/umountfs eingebaut:

Code

stop)
        sudo /sbin/stop autofs
        sleep 10
        do_stop
        ;;
  *)

und eben in die /etc/sudoers beim vdr ein /sbin/stop ergänzt.

Ziemlich sicher ist das "sudo" gar nicht nötig - die Scripte laufen wahrscheinlich eh mit root-Rechten, sonst würde der Rest ja nicht funktionieren - war mir aber nicht 100% sicher und dachte - so tuts auf jeden Fall

Dirch: Wenn es bei Dir nicht/nicht immer autofs ist, was ist es dann? Läufst Du einfach in einen Timeout? Oder aus welchem Grund wird die Videoplatte bei Dir nicht ge-unmounted (komisches Wort). Habe normal keine Tastatur an meinem VDR, der Wechsel auf die Konsole und ein "n" gehen dann nichtmehr...

steffen_b · 8. September 2010

Wir haben 2 Fehler identifiziert.

1. Der VDR ist noch nicht beendet während umountfs läuft. -> busy mount.
2. Das autofs upstart script hat einen Fehler in seiner stop on Anweisung. Auch hier sollte umountfs noch nicht laufen wenn dies nicht beendet ist.

Erst wenn beide beendet sind sollten die init.d Skripte abgearbeitet werden (upstart job rc) (stop on starting rc)

Dirch · 8. September 2010

Ich vermute, das der Shutdown einfach etwas zu flott ist und den Plattencheck ausführt bevor der VDR Prozess beendet ist und das Verzeichnis freigibt. Evtl. ist es mit einem sleep an geeigneter Stelle auch schon getan - aber solange ich einen Holzhammer habe, mache ich mir darum keinen Kopp.

Eine andere Möglichkeit ist aber auch die Tatsache, dass sich einer meiner Clients das Video Verzeichnis mit dem Server teilt, aber auch das hätte bereits vor dem fschk gelöst sein sollen.

Wie auch immer, da ja die 0.3 in den Startlöchern steht, investiere ich nicht allzuviel Energie in die optimierte Problembehandlung. Leider sind noch ein paar Betatester im Verzug und ich konnte da nicht mehr mitspielen weil die Schnarchnasen sich vorgedrängelt haben (ok, das stimmt nicht, ich war einfach nicht schnell genug.)

edit: Siehst du, schon wieder zu langsam

gda · 8. September 2010

Zitat

Original von Dirch
Leider sind noch ein paar Betatester im Verzug und ich konnte da nicht mehr mitspielen weil die Schnarchnasen sich vorgedrängelt haben (ok, das stimmt nicht, ich war einfach nicht schnell genug.)

Es könnte sein, dass bald ein paar Plätze frei werden, warte noch ein paar Tage. Jemand der weiß wie ein Bash-Skript funktioniert hat bei uns als Beta-Tester schon mal eine Einstiegshürde überwunden.

Gerald

g3joker · 8. September 2010

hallo,

danke für den heissen tip mit dem plattencheck, auf einmal schaltet sich auch zuverlässig mein imon aus (also die beleuchtung) und die setup.conf wird gespeichert.

das bei so ner kleinigkeit SO ein rattenschwanz dranhängt...fast nicht zu glauben...

dann kann die yavdr 0.3 ja nur noch eine perfekte distri werden, viele fehler kanns ja nu nicht mehr geben

danke jedenfalls an die entwickler und die betatester!

[0.2] Shutdown: force-fsck versucht fsck auf eingehängtem Dateisystem!

Jetzt mitmachen!

Teilen

Benutzer online in diesem Thema