Le moyen de vérifier est fuser -vm /mnt/dir
, qui doit être exécuté en tant que root. Il vous indiquera quels processus accèdent au point de montage.
Une alternative est lsof /mnt/dir
, qui montrera chaque fichier ouvert sur le montage. Encore une fois mieux courir en tant que root.
Vous pouvez exécuter l'un ou l'autre en tant qu'utilisateur non root, mais le résultat sera alors limité à vos processus. Les processus d'autres utilisateurs seront simplement masqués, même s'ils empêcheront le démontage du système de fichiers.
Exemple:
Watt:~# fuser -vm /mnt/Zia/src
USER PID ACCESS COMMAND
/mnt/Zia/src: root kernel mount /mnt/Zia/src
anthony 24909 ..c.. bash
anthony 25041 F.c.. gvim
Le champ "accès" vous indique comment on y accède. Dans ce cas, le noyau l’utilise comme montage (duh, mais démonter sera OK avec seulement cela). bash
l'a comme répertoire de travail actuel (il devra être dans cd
un répertoire différent avant de démonter) et gvim a le répertoire actuel et a un fichier ouvert (devra fermer ce gvim).
Watt:~# lsof /mnt/Zia/src
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
bash 24909 anthony cwd DIR 0,26 12288 3527682 /mnt/Zia/src/perl (zia.vpn.home:/home/anthony/src)
gvim 25041 anthony cwd DIR 0,26 12288 3527682 /mnt/Zia/src/perl (zia.vpn.home:/home/anthony/src)
gvim 25041 anthony 6u REG 0,26 16384 3526219 /mnt/Zia/src/perl/.utf8.c.swp (zia.vpn.home:/home/anthony/src)
Dans cette sortie, vous pouvez voir les répertoires actuels de bash et de gvim (en tant que type DIR
). Vous pouvez également voir quel fichier gvim a ouvert en écriture.
Comment forcer le problème:
fuser
a une -k
option qui enverra un signal (valeur par défaut:) SIGKILL
à chaque processus utilisant le montage. C'est un moyen assez puissant pour empêcher la monture d'être occupée. (Et bien sûr, faites attention à ce que vous faites SIGKILL
!)
umount
a une -l
option pour effectuer un démontage paresseux. Le montage sera supprimé de l'espace de noms du système de fichiers (afin que vous ne le voyiez /mnt/Zia/src
plus sous , dans l'exemple), mais il reste monté, afin que les programmes qui y ont accès puissent continuer à le faire. Lorsque le dernier programme accédant à ce programme sera fermé, le démontage aura lieu.
Il y a une dernière cause réparable d'échec de démontage, et c'est un serveur NFS en panne. Ici, vous pouvez utiliser umount -f
, mais vous risqueriez de perdre des données si vous le faites. (Le client a peut-être mis en cache des écritures qui n'ont pas encore été confirmées par le serveur, et ces écritures sont ignorées. Cependant, les applications ont déjà été prévenues que l'écriture réussissait.)