Mount zit MUUR vast.. :(

[jep]

Mensen,

Ik ga toch bijna denken dat ik met windows werk als ik het volgende zie.

Ik probeer een NFS mount te bereiken met

code:

mount 192.168.1.30:'/home/bla' /mnt/bla

Dit ging goed maar ik wou nog 1 ding veranderen en besloot hem even te umounten. Klaar.

Toen ik het nog een keer deed maakte ik een typo.. verkeerde ip! Kan gebeuren

Mijn mount bleef hangen.. ik sloot mijn terminal maar af.

Nu; 2 dagen later draait mount nog steeds. Het maakt een load van 2 (Hij draait 2 keer). Killen is onmogelijk.. ik kan zovaak killall -9 typen als ik wil.. hij gaat niet weg.

Ik had dit probleem eerder, toen draaide portmap niet. Daarna werkte het goed..

Als ik met een monitor op de server kijkt staat een error in de zin van 'kan niet verbinden met nfs server'.. dat leek me al duidelijk

Ik kan wel rebooten maar zou het toch graag draaiend po willen lossen.. ik moet toch nog veel gebruik van NFS gaan maken.

Hoe krijgen we hem weg? Killen maar niet weg gaan is iets voor NT, niet voor Linux.. dacht ik

[blaataaps]

Heb ik ook eens gehad met mount, wou een dooie smbmount umounten. enige manier is volgens mij rebooten. heb ik ook gedaan, of het voor lief nemen dat die mount blijf lopen.

[jep]

Ik zou toch graag weten wat het is, hoe het komt en wat er op een nette manier tegen is te doen

[Knoetje]

Moiieee,

Normaal gebruikt ik solaris.

In solaris 8 zit een optie in umout!!!
waar mee je forced kunt unmounten

Heb even in debian gekeken, in de man pages:

Force unmount (in case of an unreachable NFS system). (Requires kernel 2.1.116 or later.)

hmm volgens mij is dit het probleem

Het commando wat hier bij hoort is: umount -f

Shit niet goed gelezen...
Sorry onzin post...

[jep]

Zo ver ben ik ook, maar hij is niet gemount. Force umounten was me gelukt.. maar aangezien er geen mounts zijn gefixed valt er ook niets te umounten.

code:

blaat.blaathost.nl:~>uptime
  7:43pm  up 20 days,  2:43,  3 users,  load average: 2.10, 2.11, 2.09
blaat.blaathost.nl:~>ps auxc | grep mount
root    8688  0.0  0.1  1684  532 ?   D    Dec16   0:00 mount
root    9747  0.0  0.1  1684  532 ?   D    Dec16   0:00 mount
blaat.blaathost.nl:~>df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda5        2.5G  2.2G  192M  92% /
/dev/sda2         30M  9.1M   19M  32% /boot
/dev/sda7        5.7G  3.9G  1.5G  72% /var
192.168.1.126:audrey2nfs
                169G  168G  1.1G 100% /mnt/nfs
192.168.1.128:/projects/mp2
                 82G   40G   42G  49% /music
blaat.blaathost.nl:~> ps -eo pid,command,wchan | grep mount
 8688 mount 192.168.1. rpc_execute
 9747 mount 212.142.37 rpc_execute
22882 grep mount     pipe_wait
blaat.blaathost.nl:~>killall -9 mount
blaat.blaathost.nl:~>killall -9 mount
blaat.blaathost.nl:~>killall -9 mount
blaat.blaathost.nl:~>killall -9 mount
blaat.blaathost.nl:~>killall -9 mount
blaat.blaathost.nl:~>ps auxc | grep mount
root    8688  0.0  0.1  1684  532 ?   D    Dec16   0:00 mount
root    9747  0.0  0.1  1684  532 ?   D    Dec16   0:00 mount
blaat.blaathost.nl:~>df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda5        2.5G  2.2G  192M  92% /
/dev/sda2         30M  9.1M   19M  32% /boot
/dev/sda7        5.7G  3.9G  1.5G  72% /var
192.168.1.126:audrey2nfs
                169G  168G  1.1G 100% /mnt/nfs
192.168.1.128:/projects/mp2
                 82G   40G   42G  49% /music
blaat.blaathost.nl:~>

[MyDyingBride]

Een echte oplossing is het niet, maar je kan dit voorkomen door -o soft of -o intr op te geven als je mount.

[jep]

Zit deze bug nou in de kernel, in nfs, in de kernel of in mij?

[Jelmer]

Dit komt doordat er een deadlock op een I/O process optreed.. Erg irritant en eigenlijk niets tegen te beginnen (heb er iig zelf met smbmount nog geen oplossing voor gevonden)

Maar wat MyDyingBride zegt zal ik eens proberen, wie weet helpt dat..

[jep]

Weten jullie zeker dat de enige oplossing op dit moment rebooten is? Eigenlijk tegen mijn principes

[odysseus]

Hmm, status D betekent toch uninterruptible sleep? Kan me herinneren dat er een keer een thread over geweest is. Het houdt in dat dat proces nog op IO aan het wachten is, dacht ik. Helaas kwam er uit die andere thread geen antwoord, vandaar dat ik het waarschijnlijk onthouden heb.

[Verwijderd]

Breng het systeem eens naar single-user (init s of init 1 afh., van distro) en kijk dan eens of ie weg is.
('t is toch geen remote bak he?)
Op die manier heb ik ook wel eens zo'n soort proces afgeschoten (was een of ander zombie proces geloof ik)

[odysseus]

Nog even gezocht, die thread was hier. Je kunt er dus betrekkelijk weinig aan doen, het is een deadlock tussen twee processen. In die thread komt ook nog het commando 'ps -eo pid,wchan' naar voren, waarmee je kunt zien wat elk proces aan het doen is. Misschien heb je daar wat aan...

[jep]

Op maandag 17 december 2001 20:19 schreef Operations het volgende:
Breng het systeem eens naar single-user (init s of init 1 afh., van distro) en kijk dan eens of ie weg is.
('t is toch geen remote bak he?)
Op die manier heb ik ook wel eens zo'n soort proces afgeschoten (was een of ander zombie proces geloof ik)

Het is een dikke dell in een dik rek op een dikke afstand

Kan zulke dingen dus niet doen.. moet ik eerst op de trein jumpen

Vandaar.

[jep]

Ik heb ook lopen googlen. Ze hadden het erover dat een oplossing zou kunnen zijn: zorgen dat het commando kan doen wat hij wou gaan doen.

Kortom: NFS laten antwoorden op het ip dat ik prongelijk intikte.

Zou dit werken?

[Verwijderd]

Valt te proberen; ik kom in de NFS howto dit tegen:

The program accessing a file on a NFS mounted file system will hang when the server crashes. The process cannot be interrupted or killed (except by a "sure kill") unless you also specify intr. When the NFS server is back online the program will continue undisturbed from where it was. We recommend using hard, intr on all NFS mounted file systems.

(slaat op hard mounted nfs filesystems)

Maar die genoemde "sure kill" slaat volgens mij op een kill -9, en dat lijkt niet te werken...

[jep]

Kan een reboot trouwens geen probleem worden? Init 6 zal toch eerst alle processen gekilled willen zien alvorens hij gaat umounten?

[Verwijderd]

Only one way to find out

Het lijkt me niet, init geeft dacht ik alle processen eerst een TERM signaal, wacht korte tijd, geeft vervolgens alles wat nog draait een KILL, wacht wederom, en gaat vervolgens unmounten (of read-only remounten als een unmount niet lukt vanwege een hangend proces) en vervolgens rebooten.
Als je dat niet aandurft kun je misschien beter zelf zoveel mogelijk killen, unmounten of r/o remounten, syncen en een herstart forceren (reboot -f) maar dat is niet echt netjes natuurlijk...

[Verwijderd]

kan je niet met fuser ff een unmount forceren ?

[jep]

Er is niets gemount, dus valt er ook niets te umounten .

De poging om te gaan mounten is mislukt.

[Verwijderd]

Hmm, je had het verkeerde ip ingetikt.
Is er de mogelijkheid om op de nfs server een ip alias aan te maken met dat ip op dezelfde interface, en daar de nfs server naar te laten luisteren?
Dan zou hij wel eens kunnen mounten. Daarna zou een umount weer de zaak recht moeten trekken.

[jep]

Daar zat ik ook aan te denken. Die mogelijkheid is er namelijk..

Mag ik trouwens concluderen dat NFS zuigt? Ik heb er nu alweer problemen mee. Als hij niet gemount is staan alle files in die map, en / is vol. Ik verwijder die files 'locaal' en vervolgens zijn ze op de NFS mount ook weg?

Erg handig!

[Verwijderd]

Op dinsdag 18 december 2001 00:07 schreef j3p het volgende:
Daar zat ik ook aan te denken. Die mogelijkheid is er namelijk..

Mag ik trouwens concluderen dat NFS zuigt? Ik heb er nu alweer problemen mee. Als hij niet gemount is staan alle files in die map, en / is vol. Ik verwijder die files 'locaal' en vervolgens zijn ze op de NFS mount ook weg?

Erg handig!

Ja uhm, NFS mount een remote filesystem, er wordt
geen copie van gemaakt. Als je dat zou willen dan kan je
beter rsync ofzo gebruiken

[jep]

Ik wil het juist niet nee. Hij doet het wel, maar dan toch niet helemaal.

Vaag zooitje

[blaataaps]

dat is volgens mij ook juist het hele idee van nfs, dat het niet lokaal staat, maar remote : )

[jep]

Juust.

[Verwijderd]

dus dan is het ook niet echt vaag he..

[jep]

Wat ik nog niet goed begrijp he..

Is het een bug, gebruik ik een feature verkeerd of .. hoe komt dit

Als het een bug is is het misschien handig hier iets aan te doen

[Verwijderd]

Een proces dat een D in ps vertoont is niet killbaar. D betekent zoals al gezegd een "uninterruptable sleep", maar heette vroeger "Disk wait". Een D status betekent dat een proces hangt in kernel-space, waardoor het absoluut unsafe is zo'n proces te killen (het proces kan bijvoorbeeld aan het pagen zijn). De enige manier is gaan zitten poken in kernel memory, maar dat raad ik je niet aan. Een reboot is je veiligste optie.

[jep]

En wat leren we hiervan?

- Voortaan 'soft' mounten?

[jep]

Mensen. Nu: Een tijdje later hebben we net gereboot voor een zooi hangende mount processen. Nu mount ik om de backup te controleren en hangt hij meteen weer.

Dit keer heb ik wel de -o soft optie gebruikt, met hetzelfde resultaar.

Nu zit ik dus weer met een hoge load en een hangende mount. Kan het zijn dat het het NAS systeem is dat ik mount? Ik weet het anders ook niet

Hele wazige shit.. maar het moet opgelost worden. Dat is duidelijk.

[ewasx]

Welke kernel gebruik je? Ik had met 2.4.5 ook mount problemen (en met sommige andere 2.4.x x<12 kernels). de laatste paar kernels die ik gebruikt heb lijken nergens last meer van te hebben. Ik heb nu 2.4.16 geloof ik.

[TrailBlazer]

wat je zou kunnen proberen ik weet niet of het een optie is is dmv van ip redirection op de machine zelf fout ip naar goed ip te laten wijzen. Weet het dit is extreem. Anders eventueel het ip op de andere machine ff wijzigen.