Je travaille sur mon serveur, à partir duquel j'exporte un répertoire en utilisant NFS. Bien sûr, au cours de la semaine ou des redémarrages du serveur, j'ai plusieurs fois oublié d' umount
exporter le système de fichiers de mon poste de travail (qui est monté /etc/fstab
au démarrage). Entre les deux, j'ai pu umount
après le fait et remonter (je n'utilise pasautofs
):
umount -fl /data0
mount /data0
Mais cela ne fonctionne plus.
Je ne peux pas monter le répertoire exporté depuis le serveur sur un répertoire différent (le montage se bloque), mais je peux monter nfs qui a exporté dir sur une machine virtuelle exécutée sur mon poste de travail.
Ce que j'ai essayé, c'est de retirer ( rmmod
) le module nfs
et nfsv3
(ce qui ne fonctionnerait pas:) Resource temporarily unavailable
. lsof
bloque. mount
ne montre rien monté via nfs
. Tout cela est probablement le résultat de l'utilisation de 'umount -l' plusieurs fois, mais les deux premières fois, cela a fonctionné sans problème.
J'ai redémarré le serveur entre-temps, après avoir été incapable de monter sans que cela fasse la moindre différence. J'ai aussi utilisé service nfs-kernel-server restart
. Je soupçonne que tout redeviendrait normal si je redémarrais le poste de travail client.
Existe-t-il un moyen de récupérer à partir de cela et de réinitialiser le côté client nfs sur mon poste de travail sans redémarrage?
Si je ne peux pas résoudre ce problème sans redémarrage, cela ne se reproduira-t-il pas si je commence à utiliser autofs
?
lsof -b
se bloque avec comme dernières lignes:
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.
dans les lignes qui précèdent, il n'y a pas /data0
.
L'entrée dans /etc/fstab
:
192.168.0.2:/data0 /data0 nfs defaults,auto,nolock,user 0 2
lsof -b
blocage?upstart
et tout. Vous souhaitez probablement redémarrer tous les services dunfs-common
package, il semble qu'il y en ait quelques-uns. L'ordre est également important, essayez donc d'arrêter puis de commencer par ordre de dépendance. Vous voudrez probablement aussi fairerpcbind
votre dernier arrêt / premier démarrage. J'ai déjà fait ça sur Debian, mais il n'a qu'un seulnfs-common
service sympa .Réponses:
Comme @PaperMonkey l'a suggéré dans les commentaires, vous pouvez être vissé parce que vous avez utilisé les options de montage par défaut, qui incluent une nouvelle tentative pour toujours.
intr
Autrefois, c'était un moyen de faciliter l'interruption de choses bloquées sur les E / S sur un montage NFS cassé, mais maintenant c'est un no-op.SIGKILL
peut encore interrompre les processus bloqués sur NFS, du moins lenfs(5)
prétend. Consultez cette page de manuel pour les options de montage.Utilisez
soft
au lieu de la valeur par défauthard
si vous souhaitez que NFS ne réessaye pas indéfiniment.Je recommande également d'utiliser l'automonteur. Créez des liens symboliques vers / net / host / foo / bar quelque part, si vous le souhaitez.
Souvent, il est plus facile de simplement redémarrer, mais je pense qu'en théorie, vous devriez pouvoir
kill -9
(c'est- à -direkill -KILL
) tous les processus bloqués sur NFS. ALORS umount -f pourrait fonctionner. Faites juste attention à ne pas laisser la complétion de tabulation bloquer davantage de processus sur le montage NFS.la source
D
(veille disque) en ps / top est probablement bloqué sur NFS.Vous trouverez ci-dessous une liste de commandes à exécuter pour résoudre ce problème sur une distribution basée sur RPM.
Après ça:
la source
L'utilisation
autofs
permettra d'éviter ce problème à l'avenir. Le plus grand avantageautofs
est qu'il n'essaie pas de monter le répertoire jusqu'à ce que vous essayez de l'utiliser, cela signifie que vous évitez les points de montage cassés et qu'il n'essaiera pas de monter indéfiniment, vous pouvez définir un délai d'expiration pour le démontage (ce qui est normalement court). Je ne sais pas si le montage automatique tente de nouveau pendant cette période de prétimout, mais dans tous les cas, je règle normalement le délai d'expiration du montage automatique à quelques secondes seulement.Pour résoudre le problème sans redémarrer, vous pourrez peut- être vous débrouiller avec
umount -a
(démonter tout ce qui est mentionné dans / etc / fstab)mount -a
(monter tout dans / etc / fstab) mais je l'ai sauf si le répertoire que vous avez perdu contient le répertoire personnel que vous ' mieux vaut sauvegarder le travail ailleurs et juste redémarrer.la source
Utilisez les résultats de la commande lsof pour trouver les processus sur le client contenant des références au système de fichiers périmé et tuer ces processus.
umount -f / data0
assurez-vous que vous pouvez envoyer une requête ping au serveur puis remonter le lecteur. Redémarrez tous les processus souhaités.
Clusters
Remarque: si vous exécutez une configuration de serveur de cluster, vous obtiendrez un descripteur de fichier nfs périmé à chaque fois que le serveur doit basculer. Pour éviter cela, vous devez exporter vos systèmes de fichiers à l'aide de l'option fsid. Le numéro du fsid doit être le même pour chaque système de fichiers respectif sur les deux serveurs. C'est à vous de garantir la réplication des fichiers. Voir l'extrait de la page de manuel ci-dessous:
fsid = num | root | uuid NFS doit être en mesure d'identifier chaque système de fichiers qu'il exporte. Normalement, il utilisera un UUID pour le système de fichiers (si le système de fichiers a une telle chose) ou le numéro de périphérique du périphérique contenant le système de fichiers (si le système de fichiers est stocké sur le périphérique). Comme tous les systèmes de fichiers ne sont pas stockés sur des périphériques et que tous les systèmes de fichiers n'ont pas d'UUID, il est parfois nécessaire de dire explicitement à NFS comment identifier un système de fichiers. Cela se fait avec l'option fsid =.
Pour NFSv4, il existe un système de fichiers distinct qui est la racine de tous les systèmes de fichiers exportés. Ceci est spécifié avec fsid = root ou fsid = 0, les deux signifiant exactement la même chose.
D'autres systèmes de fichiers peuvent être identifiés par un petit entier ou un UUID qui devrait contenir 32 chiffres hexadécimaux et une ponctuation arbitraire.
Les noyaux Linux version 2.6.20 et antérieures ne comprennent pas le paramètre UUID, donc un petit entier doit être utilisé si une option fsid doit être définie pour ces noyaux. La définition d'un petit nombre et d'un UUID est prise en charge afin que la même configuration puisse être effectuée pour fonctionner sur les noyaux anciens et nouveaux.
la source