Niet te killen processen naar mislukken NFS mount

Pagina: 1
Acties:

  • Mark
  • Registratie: Juni 1999
  • Laatst online: 21:45
Na een upgrade van de nfs-utils op mijn slackware 8.1 servers wilde ik netjes mijn bestaande NFS shares van een server opnieuw mounten op een bepaald systeem. Helaas ging dit mounten de mist in met een superblock melding.
Na de foutmelding heb ik eens gekeken welke processen er draaiden (wellicht draaide de portmapper nog niet oid) en zag deze 2 processen:
code:
1
2
16669 ?        SW     0:00 [rpciod]
 5132 ?        SW     0:00 [lockd]

Proberen te killen dan maar. Dus ik die processen een KILL gestuurd, maar ze bleven maar bestaan. Op dit moment is het mount point voor de NFS share ook nog gelocked (waarschijnlijk dus door die 2 processen), dus ik kan nog niet eens opnieuw proberen om de NFS export onder deze directory te mounten.
Is er manier om alsnog deze processen te killen (zonder te rebooten) ?

  • VisionMaster
  • Registratie: Juni 2001
  • Laatst online: 17-03 00:12

VisionMaster

Security!

kill -9 geprobeerd en als root al geprobeerd te killen ?

I've visited the Mothership @ Cupertino


  • Mark
  • Registratie: Juni 1999
  • Laatst online: 21:45
VisionMaster schreef op 17 juli 2003 @ 01:30:
kill -9 geprobeerd en als root al geprobeerd te killen ?
kill -9 = KILL...en ja, dit doe ik natuurlijk als root....

  • VisionMaster
  • Registratie: Juni 2001
  • Laatst online: 17-03 00:12

VisionMaster

Security!

Mark schreef op 17 July 2003 @ 01:32:
[...]
kill -9 = KILL...en ja, dit doe ik natuurlijk als root....
Sqeeze me ... ik werk niet met Slack...
veel FuN

I've visited the Mothership @ Cupertino


  • sebas
  • Registratie: April 2000
  • Laatst online: 16-12-2025
Misschien kun je met lsof eracher komen welk proces je nfs mount lockt?

Everyone complains of his memory, no one of his judgement.


  • Valium
  • Registratie: Oktober 1999
  • Laatst online: 04-05 20:39

Valium

- rustig maar -

Zelfde probleem gehad met een pre-woody debian systeem. Ik wil je hoop niet de grond indrukken, maar ik kon niets anders vinden dan rebooten (wat op zich niet zo'n probleem is tenzij het een production-server is). Het zou kunnen dat er een timeout in zit van enkele minuten...maar ik dacht het niet. Misschien kun je d'r een soft mount van maken in plaats van een hard mount. Dan komt er gewoon een foutmelding naar boven drijven en is alles weer koek ende ei.
code:
1
2
kill = QUIT
kill -9 = KILL

Kijk maar eens in de manual van kill :Y)

  • blaataaps
  • Registratie: Juli 2001
  • Niet online
reboot is waarschijnlijk de enige optie inderdaad.
nfs-processen die geen reactie meer krijgen zijn tamelijk hardnekkig in hun uninterruptable sleep, oplossing is rebooten, of zorgen dat ie weer reactie krijgt. Tips om dit te voorkomen in de toekomst te voorkomen, zijn idd soft mounten (hoewel de meningen daarover verdeeld zijn, er was een reden om dit niet te doen, maar weet niet meer welke : ), en tcp gebruiken ipv udp schijnt ook een goed idee te zien, als server en client dit allebei snappen, 'verbindingen' en hun status zijn wat netter bij te houden met tcp dan met udp.

  • Mark
  • Registratie: Juni 1999
  • Laatst online: 21:45
Tsjah, aangezien het een productie server is is rebooten niet echt een oplossing. Op dit moment heb ik het tijdelijk opgelost door de oude NFS exports maar elke miunuut met rsync te syncen (het gaat om bestanden welke door gebruikers worden geupload).

Ik ben net bezig geweest om de NFS exports op een andere server te mounten, maar dat lukte dus ook niet meer. Ik vermoed dus dat er met de NFS server zelf iets mis is.
Heb zojuist NFS gestopt en opnieuw gestart, maar het lukte nog steeds niet. Een rpcinfo gaf ook niet aan dat nfs loopt op de server. Ik vermoed dat de nfsd kernel module dwars ligt, leuke daarvan is dat ik deze niet kan unloaden omdat hij mekkert dat die module busy is (ook als rpc.mountd enzo gestopt zijn).
Is er wellicht een manier om deze module keihard te unloaden ?
Valium schreef op 17 July 2003 @ 12:01:
code:
1
2
kill = QUIT
kill -9 = KILL

Kijk maar eens in de manual van kill :Y)
Daarom schreef ik ook KILL met hoofdletters :) Ik gebruik dus ook gewoon kill -9

[ Voor 19% gewijzigd door Mark op 17-07-2003 13:10 ]


  • Heidistein
  • Registratie: Februari 2002
  • Laatst online: 08-04 20:21

Heidistein

Blah

Het enige dat ik heb kunnen vinden hiervoor is een reboot. Helaas.
Maar AFAIK probeert een NFSd constant een NFS mount te herstellen als deze mislukt. Mischien kan je op de NFS server de export herstellen , zodat deze gemount kan worden waardoor de kernel de processen weer ondooit...
(Geen garantie hoor, just a guess)

Maybee we are alone... After all.


  • Mark
  • Registratie: Juni 1999
  • Laatst online: 21:45
Heidistein schreef op 17 juli 2003 @ 13:30:
Het enige dat ik heb kunnen vinden hiervoor is een reboot. Helaas.
Maar AFAIK probeert een NFSd constant een NFS mount te herstellen als deze mislukt. Mischien kan je op de NFS server de export herstellen , zodat deze gemount kan worden waardoor de kernel de processen weer ondooit...
(Geen garantie hoor, just a guess)
Probleem zit hem nu juist in de nfsd op de server zelf. Die draait als kernel module welke ik niet kan verwijderen met rmmod. Ik heb alle bestaande NFS connecties richting die server gestopt en alle aanverwante processen. Toch word de module niet netjes vrijgegeven.

Verwijderd

als je /etc/exports leeg maakt en mountd HUPt?
Pagina: 1