kernel module entladen, FATAL: Module lufs is in use
Hallo, ich spiele gerade mit lufs herum und kann es nach einem Haenger von lufsmount das kernel module nicht mehr entladen. (lufsmount habe ich mit -9 gekillt) $modprobe -r lufs FATAL: Module lufs is in use. Wie kann ich herausfinden wer oder was dieses module benutzt? Hier noch ein paar Infos: & uname -r uname -r 2.6.5-7.111.19-custom $ lsmod Module Size Used by lufs 20096 1 isofs 28472 0 zlib_inflate 20480 1 isofs ipt_MASQUERADE 2944 0 quota_v2 7808 1 iptable_mangle 2176 0 iptable_nat 17964 1 ipt_MASQUERADE ip6table_filter 2176 0 ip6_tables 15632 1 ip6table_filter ipt_limit 1920 3 ipt_state 1536 10 ip_conntrack 25136 3 ipt_MASQUERADE,iptable_nat,ipt_state iptable_filter 2304 1 ip_tables 14336 6 ipt_MASQUERADE,iptable_mangle,iptable_nat,ipt_limit,ipt_state,iptable_filter ipv6 207936 33 af_packet 15112 2 e100 27776 0 mii 4096 1 e100 $ lsof |grep -i lufs #nichts Wuerde dieses Problem gern ohne reboot loesen. cu Ruediger
Am Freitag, 11. März 2005 11:25 schrieb Ruediger Meier:
ich spiele gerade mit lufs herum und kann es nach einem Haenger von lufsmount das kernel module nicht mehr entladen. (lufsmount habe ich mit -9 gekillt)
$modprobe -r lufs FATAL: Module lufs is in use.
Ist noch in gebrauch von (vermutlich) einem anderen Modul.
Wie kann ich herausfinden wer oder was dieses module benutzt?
Ich wüsste da leider nur eine try and error Variante. Du hast ja eine schöne Liste von den Modulen weiter unten in der Mail. modprobe --show-depends isofs Und so weiter, bis Du das Modul gefunden hast. Aber das geht mit Sicherheit auch eleganter. Ich weiß leider nicht was lufs macht, so kann ich aus der Liste unten auch nichts auslesen, wer denn da noch dazu gehören könnte.
Hier noch ein paar Infos:
& uname -r uname -r 2.6.5-7.111.19-custom
$ lsmod Module Size Used by lufs 20096 1 ^^ isofs 28472 0
[...lsmod output...] Gruß Thomas
On Friday 11 March 2005 12:51, Thomas Janssen wrote:
Wie kann ich herausfinden wer oder was dieses module benutzt?
Ich wüsste da leider nur eine try and error Variante. Du hast ja eine schöne Liste von den Modulen weiter unten in der Mail.
modprobe --show-depends isofs
Und so weiter, bis Du das Modul gefunden hast.
Ich denke dass es nicht von einem anderen modul genutzt wird, sonst wuerde dieses IMO in der "Used by" Spalte auftauchen.
Aber das geht mit Sicherheit auch eleganter.
Ich das trotzdem mal durchprobiert - leider erfolglos.
Ich weiß leider nicht was lufs macht, so kann ich aus der Liste unten auch nichts auslesen, wer denn da noch dazu gehören könnte.
Mit lufs kann man z.B ein ftp-Verzeichnis in den lokalen Verzeichnisbaum mounten. Im Prinzip ist also ein "mount -t lufs" abgestuerzt - vielleicht hilft das. Ich denke es sollte irgendwie eine allgemeine Moeglichkeit geben um den Benutzer eines Moduls festzustellen. Wenn z.B. vfat nicht momentan geladen ist und man macht $ modprobe vfat #meist unnoetig $ mount -t vfat /dev/hdxy /mnt wie finde ich dann andersherum heraus, dass ich /mnt umounten muss, bevor man vfat wieder entladen kann? (vfat ist jetzt ein Beispiel - es koennte ebensogut ein anderes Modul sein bei dem man nicht offensichtlich sieht was zu tun ist.) cu, Ruediger
Hallo, On 11-Mar-2005 Ruediger Meier wrote:
Hallo, ich spiele gerade mit lufs herum und kann es nach einem Haenger von lufsmount das kernel module nicht mehr entladen. (lufsmount habe ich mit -9 gekillt)
Steht da vielleicht noch etwas in der /etc/mtab? Ein kill -9 bekommt die mtab nicht mit. Beste Gruesse, Heinz. -- http://www.pahlke-online.de/reisenews/ http://www.Pahlke-KunstWebDesign.de/
On Friday 11 March 2005 15:14, Heinz W. Pahlke wrote:
Hallo,
On 11-Mar-2005 Ruediger Meier wrote:
ich spiele gerade mit lufs herum und kann es nach einem Haenger von lufsmount das kernel module nicht mehr entladen. Steht da vielleicht noch etwas in der /etc/mtab?
Nee, da war nichts. Ich habs nicht geschafft herauszufinden wer oder was das Modul blockiert hat! Ich habe es dann dummerweise mit $ modprobe --force lufs entladen. (interesanterweise ging "rmmod -f" nicht) Erst hab ich mich gefreut. Dann aber hagelte es segmentation faults z.B bei einem einfachen "ls"! Die laufenden Dienste (apache, mysql, gameservers etc) liefen aber gut weiter. Nur - ich konnte mich dann nicht mehr einloggen! Bei ssh gabs "authentification failure" o.ä. serial console gab mir: Mar 13 14:50:32 h52614 kernel: Code: 8b 10 89 e8 e8 c4 1c 00 00 8b 7c 24 0c ba ff ff ff ff 8b 47 Mar 13 14:50:32 h52614 kernel: <1>Unable to handle kernel paging request at virtual address e08fc920 Mar 13 14:50:32 h52614 kernel: printing eip: Mar 13 14:50:32 h52614 kernel: c0168913 Mar 13 14:50:32 h52614 kernel: *pde = 1ff67067 Mar 13 14:50:32 h52614 kernel: *pte = 00000000 Mar 13 14:50:32 h52614 kernel: Oops: 0000 [#4023] Mar 13 14:50:32 h52614 kernel: CPU: 0 Mar 13 14:50:32 h52614 kernel: EIP: 0060:[show_vfsmnt+125/607] Tainted: GF U Mar 13 14:50:32 h52614 kernel: EIP: 0060:[<c0168913>] Tainted: GF U Mar 13 14:50:32 h52614 kernel: EFLAGS: 00010206 (2.6.5-7.111.19-custom) Mar 13 14:50:32 h52614 kernel: EIP is at show_vfsmnt+0x7d/0x25f Mar 13 14:50:32 h52614 kernel: eax: e08fc920 ebx: c028d560 ecx: c0287e9f edx: 000000bd Mar 13 14:50:32 h52614 kernel: esi: d589e200 edi: dffe4a80 ebp: d589e200 esp: c16cff00 Mar 13 14:50:32 h52614 kernel: ds: 007b es: 007b ss: 0068 Mar 13 14:50:32 h52614 kernel: Process cp (pid: 11873, threadinfo=c16ce000 task=dfe0cc10) Mar 13 14:50:32 h52614 kernel: Stack: c0287e9f c02b3a58 00000000 dffe4a80 c02b39e0 d589e200 dffe4a80 000000b4 Mar 13 14:50:32 h52614 kernel: c016ae14 d589e218 00000000 00000fff 08056008 00000007 00000000 00000006 Mar 13 14:50:32 h52614 kernel: 00000000 c02b47c0 dec80b80 00000fff dec80ba4 c0150ad4 dec80ba4 dea7ad90 Mar 13 14:50:32 h52614 kernel: Call Trace: Mar 13 14:50:32 h52614 kernel: [seq_read+664/703] seq_read+0x298/0x2bf Mar 13 14:50:32 h52614 kernel: [<c016ae14>] seq_read+0x298/0x2bf Mar 13 14:50:32 h52614 kernel: [vfs_read+164/260] vfs_read+0xa4/0x104 Mar 13 14:50:32 h52614 kernel: [<c0150ad4>] vfs_read+0xa4/0x104 Mar 13 14:50:32 h52614 kernel: [sys_read+133/198] sys_read+0x85/0xc6 Mar 13 14:50:32 h52614 kernel: [<c0150d00>] sys_read+0x85/0xc6 Mar 13 14:50:32 h52614 kernel: [sysenter_past_esp+82/113] sysenter_past_esp+0x52/0x71 Mar 13 14:50:32 h52614 kernel: [<c0106d2d>] sysenter_past_esp+0x52/0x71 Mar 13 14:50:32 h52614 kernel: Also musste ich einen harten Reset machen! Oder funktioniert auf der seriellen console irgendeine Tasten-Kombination, um ordentlich zu rebooten? cu Ruediger
Hallo Leute, Am Montag, 14. März 2005 13:10 schrieb Ruediger Meier: [...]
serial console gab mir:
Mar 13 14:50:32 h52614 kernel: Code: 8b 10 89 e8 e8 c4 1c 00 00 8b 7c 24 0c ba ff ff ff ff 8b 47 Mar 13 14:50:32 h52614 kernel: <1>Unable to handle kernel paging request at virtual address e08fc920 [...]
Ein Kernel-Oops. Böse.
Also musste ich einen harten Reset machen! Oder funktioniert auf der seriellen console irgendeine Tasten-Kombination, um ordentlich zu rebooten?
Wenn das Einloggen (und damit init 6) nicht mehr geht, fällt mir höchstens noch SysRQ ein. Ob man das aber per serieller Konsole machen kann, weiß ich leider nicht. (zum Testen besser SysRq S (sync) und nicht SysRq U B (umount, reboot) verwenden ;-) Doku zu SysRq: /usr/src/linux/Documentation/sysrq.txt "SysRq" ist üblicherweise die Tastenkombination Alt+PrintScreen Gruß Christian Boltz -- Why should I read the fucking manual? I know how to fuck!
Hallo, Am Mon, 14 Mar 2005, Christian Boltz schrieb:
Am Montag, 14. März 2005 13:10 schrieb Ruediger Meier: [...]
serial console gab mir:
Mar 13 14:50:32 h52614 kernel: Code: 8b 10 89 e8 e8 c4 1c 00 00 8b 7c 24 0c ba ff ff ff ff 8b 47 Mar 13 14:50:32 h52614 kernel: <1>Unable to handle kernel paging request at virtual address e08fc920 [...]
Ein Kernel-Oops. Böse.
Und zwar im VFS (Virtual File System).
Also musste ich einen harten Reset machen! Oder funktioniert auf der seriellen console irgendeine Tasten-Kombination, um ordentlich zu rebooten?
Wenn das Einloggen (und damit init 6) nicht mehr geht, fällt mir höchstens noch SysRQ ein. Ob man das aber per serieller Konsole machen kann, weiß ich leider nicht. (zum Testen besser SysRq S (sync) und nicht SysRq U B (umount, reboot) verwenden ;-)
Doku zu SysRq: /usr/src/linux/Documentation/sysrq.txt "SysRq" ist üblicherweise die Tastenkombination Alt+PrintScreen
Besser wie in der Doku geschrieben: SysRq+s SysRq+s SysRq+u SysRq+b Dabei werden uebrigens auf der Konsole vor tty10 [1] Meldungen ausgegeben. SysRq : Emergency Sync Syncing device 16:05 ... OK [..] Syncing device 03:4a ... OK Done. Auch zum umount wird was ausgegeben... Das sieht man halt nur, wenn man noch auf die Konsole kommt ;) Ansonsten kann man nur hoffen, dass man das syncen der Festplatten hoert (da sind laute Seagates etc. mal von Vorteil ;) und dann eben wie o.g. weiter. Achso: mir faellt auch nix ein, wenn das VFS einen Knacks hat wuerde ich auf jeden Fall rebooten, unabhaengig davon, ob es noch eine andere Moeglichkeit gibt. Wie's scheint, hab ich mit meiner Entscheidung auf lufs zu verzichten, weil mir das doch etwas suspekt vorkam, keine schlecte solche getroffen. HTH, -dnh [1] ich schreibe nicht tty9, weil das kein normales tty wie tty10 ist, denn man hat z.B. keinen Zugriff auf /dev/vcs9 (aber auf /dev/vcs10). Auch kommt man mit Strg+Alt+F9 nicht hin wie mit +F10 zu tty10. Naja, mit xemacs und gpm bekommt man das auch so einfach per C&P in diese Mail :) -- Ich soll keine fünfzeiligen Signaturen schreiben. Ich soll keine fünfzeiligen Signaturen schreiben. Ich soll keine fünfzeiligen Signaturen schreiben. Ich soll keine fünfzeiligen Signaturen schreiben. Ich soll keine fünf...
participants (6)
-
Christian Boltz -
David Haller -
Heinz W. Pahlke -
Ruediger Meier -
Thomas Hertweck -
Thomas Janssen