reiniciar el cliente NFS sin reiniciar

He estado trabajando en mi servidor, desde el cual exporto un directorio usando NFS. Por supuesto, durante la semana de reinicios del servidor, olvidé varias veces umountel sistema de archivos de exportación en mi estación de trabajo (que se monta desde /etc/fstabel arranque). Entre pude umountdespués de los hechos y volver a montar (estoy no usando autofs):

umount -fl /data0
mount /data0

Pero esto ya no funciona.

No puedo montar el directorio exportado desde el servidor en un directorio diferente (el montaje se bloquea), pero no puedo montar ese directorio exportado en una máquina virtual que se ejecuta en mi estación de trabajo.

Lo que intenté es eliminar ( rmmod) el módulo nfsy nfsv3(que no funcionaría Resource temporarily unavailable). lsofse cuelga mountno muestra nada montado a través de nfs. Probablemente todo esto sea el resultado de usar 'umount -l' varias veces, pero las dos primeras veces esto funcionó sin problemas.

He reiniciado el servidor mientras tanto, después de no poder montar sin que eso haya hecho ninguna diferencia. Yo también lo usé service nfs-kernel-server restart. Sospecho que todo volvería a la normalidad si reinicio la estación de trabajo del cliente.

¿Hay alguna manera de recuperarse de esto y reiniciar el lado del cliente nfs en mi estación de trabajo sin reiniciar?
Si no puedo solucionar esto sin reiniciar, ¿no volvería a ocurrir esto si empiezo a usarlo autofs?

lsof -b cuelga con las últimas líneas:

lsof: avoiding readlink(/run/user/1001/gvfs): -b was specified.
lsof: avoiding stat(/run/user/1001/gvfs): -b was specified.
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1001/gvfs
      Output information may be incomplete.

en las líneas que preceden eso, no hay /data0.

La entrada en /etc/fstab:

192.168.0.2:/data0 /data0  nfs  defaults,auto,nolock,user 0 2

Como @PaperMonkey sugirió en los comentarios, es posible que te jodas porque usaste las opciones de montaje predeterminadas, que incluyen volver a intentarlo para siempre.

intrsolía ser una forma de facilitar la interrupción de cosas que estaban atascadas en E / S en un soporte NFS roto, pero ahora es un no-op. SIGKILLTodavía puede interrumpir procesos atascados en NFS, al menos así lo nfs(5)afirman. Consulte esa página de manual para ver las opciones de montaje.

Use en softlugar del predeterminado hardsi desea que NFS no vuelva a intentarlo para siempre.

También recomiendo usar el montador automático. Haga enlaces simbólicos a / net / host / foo / bar en algún lugar, si lo desea.

A menudo es más fácil reiniciar, pero creo que en teoría debería poder kill -9(es decir kill -KILL) cualquier proceso que esté atascado en NFS. ENTONCES umount -f podría funcionar. Solo tenga cuidado de no permitir que la finalización de pestañas bloquee más procesos en el montaje NFS.

A continuación se muestra una lista de comandos para ejecutar para solucionar este problema en una distribución basada en RPM.

service rpcbind stop
service nfslock stop
rm -rf /var/lib/nfs/statd/sm/*
rm -rf /var/lib/nfs/statd/sm.bak/*

Después de esto:

umount -f /share

El uso autofsayudará a evitar este problema en el futuro. El mayor beneficio autofses que no intenta montar el directorio hasta que intente usarlo, esto significa que evita los puntos de montaje rotos y que no intentará montarse indefinidamente, puede establecer un período de tiempo de espera para el desmontaje (que normalmente es corto). No estoy seguro de si el remontaje automático vuelve a intentarlo durante este período de anticipación, pero de cualquier manera, normalmente configuro el tiempo de espera del desmontaje automático en solo unos segundos.

Para resolver el problema sin reiniciar, puede salir adelante umount -a(desmontar todo lo mencionado en / etc / fstab) mount -a(montar todo en / etc / fstab) pero a menos que el directorio que ha perdido contenga el directorio de inicio es mejor guardar el trabajo en otro lugar y simplemente reiniciar.

Use los resultados del comando lsof para encontrar los procesos en el cliente que contienen referencias al sistema de archivos obsoletos y elimine esos procesos.

umount -f / data0

asegúrese de que puede hacer ping al servidor y luego volver a montar la unidad. Reinicie los procesos deseados.

Racimos

Tenga en cuenta que si ejecuta una configuración de servidor de clúster, obtendrá un identificador de archivo nfs obsoleto cada vez que el servidor deba fallar. Para evitar eso, debe exportar sus sistemas de archivos utilizando la opción fsid. El número para el fsid debe ser el mismo para cada sistema de archivos respectivo en los dos servidores. Depende de usted asegurar que se produzca la replicación de los archivos. Vea el fragmento de la página de manual a continuación:

fsid = num | root | uuid NFS necesita poder identificar cada sistema de archivos que exporta. Normalmente usará un UUID para el sistema de archivos (si el sistema de archivos tiene tal cosa) o el número de dispositivo del dispositivo que contiene el sistema de archivos (si el sistema de archivos está almacenado en el dispositivo). Como no todos los sistemas de archivos están almacenados en dispositivos, y no todos los sistemas de archivos tienen UUID, a veces es necesario decirle explícitamente a NFS cómo identificar un sistema de archivos. Esto se hace con la opción fsid =.

Para NFSv4, hay un sistema de archivos distinguido que es la raíz de todos los sistemas de archivos exportados. Esto se especifica con fsid = root o fsid = 0, lo que significa exactamente lo mismo.

Se pueden identificar otros sistemas de archivos con un número entero pequeño o un UUID que debe contener 32 dígitos hexadecimales y puntuación arbitraria.

Los núcleos de Linux versión 2.6.20 y anteriores no entienden la configuración de UUID, por lo que se debe usar un número entero pequeño si es necesario establecer una opción fsid para dichos núcleos. Se admite la configuración de un número pequeño y un UUID, por lo que se puede hacer que la misma configuración funcione tanto en los núcleos antiguos como en los nuevos.