web-dev-qa-db-fra.com

Appareil occupé sur Umount

Je rencontre souvent un problème pour démonter un répertoire:

umount /mnt/dir[.____.[umumount:/mnt/dir: le périphérique est occupé

Il y a plusieurs raisons pour lesquelles l'appareil est occupé. Parfois, il y a des processus en cours d'exécution qui ont des verrous ouverts, parfois il y a d'autres répertoires montés sur /mnt/dir.

Ma question:

Quelles sont les étapes pour vérifier pourquoi un répertoire n'a pas pu être démonté.

Je sais qu'il y a plusieurs raisons, mais ce n'est pas grave si vous expliquez une solution spécifique.

[ÉDITER]

[X] exécution de processus sur des volumes montés.
[X] un autre volume est monté sur un volume que nous voulons démonter
[_] NFS verrouille le volume que nous voulons démonter

linuxunmounting
42
user55518

La façon 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 affichera chaque fichier ouvert sur le support. Encore une fois mieux exécuté en tant que root.

Vous pouvez exécuter l'un ou l'autre en tant que non root, mais la sortie sera limitée à vos processus - ceux des autres utilisateurs ne seront tout simplement pas affiché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 y accéder. Dans ce cas, le noyau l'utilise en tant que montage (duh, mais le démontage ne sera OK qu'avec cela). bash l'a comme répertoire de travail actuel (devra cd dans un autre répertoire avant de démonter) et gvim a le répertoire actuel et 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 pour bash et gvim (de type DIR). Vous pouvez également voir quel fichier gvim a ouvert pour l'écriture.

Comment forcer le problème:

fuser a un -k option qui enverra un signal (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 SIGKILL!)

umount a un -l option pour effectuer un démontage paresseux. Le montage sera supprimé de l'espace de noms du système de fichiers (vous ne le verrez donc pas sous /mnt/Zia/src plus, dans l'exemple) mais il reste monté, donc les programmes qui y accèdent peuvent continuer à le faire. Lorsque le dernier programme y accédant se ferme, le démontage se produit réellement.

Il existe une dernière cause réparable d'échec du démontage, et c'est un serveur NFS qui tombe en panne. Ici, vous pouvez utiliser umount -f, mais vous risquez de perdre des données si vous le faites. (Le client peut avoir mis en cache des écritures qui n'ont pas encore été confirmées par le serveur, et ces écritures seront rejetées. Cependant, les applications ont déjà été informées que l'écriture a réussi.)

78
derobert

Tu devrais utiliser:

Sudo umount -l <path>

De la page de manuel :

-l, --lazy

    Démontage paresseux. Détachez maintenant le système de fichiers de la hiérarchie de fichiers et nettoyez toutes les références à ce système de fichiers dès qu'il n'est plus occupé.

    Un redémarrage du système est attendu dans un avenir proche si vous comptez utiliser cette option pour un système de fichiers réseau ou un système de fichiers local avec des sous-montages. Cas d'utilisation recommandé pour umount -l est d'empêcher les blocages à l'arrêt en raison d'un partage réseau inaccessible où un umount normal se bloquera en raison d'un serveur en panne ou d'une partition réseau. Les remises de part ne seront pas possibles.

23
Felipe

n autre volume est monté au-dessus d'un volume que nous voulons démonter:

La commande mount vous permet de connaître tous les volumes montés si elle est invoquée sans arguments ni options (sauf -v). Vous pouvez avoir une liste de points de montage actifs en ajoutant un peu de Perl:

mount | Perl -pe 's/.*on (\S+) type.*/\1/'

Ensuite, grep juste sur le mointpoint à partir duquel vous souhaitez démonter et vous saurez s'il y a des systèmes de fichiers montés sur celui-ci.

mount | Perl -pe 's/.*on (\S+) type.*/\1/' | grep '/mnt/dir/'

Vous avez alors deux solutions. Démontez les systèmes de fichiers ou déplacez-les avec mount --move olddir newdir (noyau> 2.5.1)

6
mveroone

Ouvrir des fichiers

Les processus avec des fichiers ouverts sont les coupables habituels. Affichez-les:

lsof +f -- <mountpoint or device>

Il y a un avantage à utiliser /dev/<device> plutôt que /mountpoint: un point de montage disparaîtra après un umount -l, ou il peut être masqué par un support superposé.

fuser peut également être utilisé, mais à mon avis lsof a une sortie plus utile. Cependant, fuser est utile lorsqu'il s'agit de tuer les processus à l'origine de vos drames afin que vous puissiez continuer votre vie.

Lister les fichiers sur <mountpoint> (voir la mise en garde ci-dessus):

fuser -vmM <mountpoint>

Ne tuez interactivement que les processus avec des fichiers ouverts pour l'écriture:

fuser -vmMkiw <mountpoint>

Après remontage en lecture seule (mount -o remount,ro <mountpoint>), il est sûr (r) de tuer tous les processus restants:

fuser -vmMk <mountpoint>

Points de montage

Le coupable peut être le noyau lui-même. Un autre système de fichiers monté sur le système de fichiers que vous essayez de umount causera des problèmes. Vérifier avec:

mount | grep <mountpoint>/

Pour les montages en boucle, vérifiez également la sortie de:

losetup -la

Inodes anonymes (Linux)

inodes anonymes peut être créé par:

  • Fichiers temporaires (open avec O_TMPFILE)
  • inotify montres
  • [eventfd]
  • [eventpoll]
  • [timerfd]

Ce sont les pokémons les plus insaisissables et apparaissent dans la colonne lsof de TYPE sous la forme a_inode (non documenté dans la page de manuel lsof ).

Ils n'apparaîtront pas dans lsof +f -- /dev/<device>, vous devrez donc:

lsof | grep a_inode

Pour tuer les processus contenant des inodes anonymes, voir: Liste des montres inotify actuelles (chemin d'accès, PID) .

3
Tom Hale

Pour moi, le problème était que j'étais connecté plus d'une fois (via ssh) et sur l'une des connexions, j'étais à l'invite de commande où le pwd était dans un dossier subordonné au point de montage.

1
Lonniebiz

La question de savoir si NFS accède à un répertoire qui va être démonté est toujours sans réponse.

Ce que j'ai, c'est seulement ceci:

Vérifiez si nfsd est en cours d'exécution:

pidof nfsd

Afficher les répertoires montés par les clients:

showmount -a

et showmount sans arguments affiche uniquement les hôtes clients même s'ils sont hors ligne. Je suppose que c'est un comportement spécial de NFS.

1
user55518