umount: le périphérique est occupé. Pourquoi?

172

En courant umount /pathje reçois:

umount: /path: device is busy.

Le système de fichiers est énorme, donc ce lsof +D /pathn’est pas une option réaliste.

lsof /path, lsof +f -- /pathEt fuser /pathtout retour rien. fuser -v /pathdonne:

                  USER        PID ACCESS COMMAND
/path:            root     kernel mount /path

ce qui est normal pour tous les systèmes de fichiers montés inutilisés.

umount -let umount -fn'est pas assez bon pour ma situation.

Comment comprendre pourquoi le noyau pense que ce système de fichiers est occupé?

Ole Tange
la source
11
Le répertoire actuel de votre shell est-il sur le chemin du point de montage?
LawrenceC
Non, alors le fuser le dirait.
Ole Tange
12
Vous voulez réellement fuser -vm /path...
derobert
5
Car umount --forcetentera plus difficile de démonter et, -vou -vvvmême, révélera davantage quel est le problème avec mount. Alors essayez:umount -vvv --force /babdmount
gaoithe

Réponses:

139

Il semble que la cause de mon problème était l' nfs-kernel-serverexportation du répertoire. Le nfs-kernel-serverva probablement derrière les fichiers ouverts normaux et n'est donc pas listé par lsofet fuser.

Quand j'ai arrêté le nfs-kernel-serverje pourrais umountle répertoire.

J'ai créé une page avec des exemples de toutes les solutions jusqu'ici ici: http://oletange.blogspot.com/2012/04/umount-device-is-busy-why.html

Ole Tange
la source
54
Merci d'avoir répondu à votre propre question au lieu de l'abandonner lors de la mise en œuvre de votre solution. Votre réponse m'a aidé à trier un partage NFS exporté de la même manière.
Jeff Welling
7
Ce même problème peut également se produire si vous avez configuré des périphériques de bouclage sur le système de fichiers, par exemple si / dev / loop0 est sauvegardé par un fichier dans / path.
BCran
1
Je devais d' sudo service samba stopabord, votre réponse a vraiment aidé!
Malat
1
Ce message m'a rappelé que le service NFS fonctionnait après plusieurs heures d’essai de le comprendre. Dans RHEL6 / CentOS6, utilisez-le sudo service nfs stopet vous n’avez peut-être pas besoin de le faire sudo exportfs -upour annuler l’export. N'oubliez pas ensuite sudo exportfs -ret sudo service nfs startde réexporter et redémarrez le service.
code_dredd
1
Dans mon cas, il n'était pas nécessaire d'arrêter le serveur nfs, mais uniquement exportfs -ule répertoire en question.
Law29
41

Pour ajouter à BruceCran de commentaire ci - dessus, la cause de ma manifestation de ce problème tout à l' heure était un rassis montage réalimentation. J'avais déjà vérifié la sortie de fuser -vm <mountpoint>/ lsof +D <mountpoint>, mountet cat /proc/mountsvérifié si un ancien serveur nfs-kernel-server était en cours d'exécution, désactivé les quotas, tenté (mais échoué) a umount -f <mountpoint>et me suis presque résigné à abandonner la disponibilité de 924 jours avant de vérifier enfin la sortie de losetupet de trouver deux rassis bouclages configuré, mais non pas montés:

parsley:/mnt# cat /proc/mounts 
rootfs / rootfs rw 0 0
none /sys sysfs rw,nosuid,nodev,noexec 0 0
none /proc proc rw,nosuid,nodev,noexec 0 0
udev /dev tmpfs rw,size=10240k,mode=755 0 0
/dev/mapper/stuff-root / ext3 rw,errors=remount-ro,data=ordered 0 0
tmpfs /lib/init/rw tmpfs rw,nosuid,mode=755 0 0
usbfs /proc/bus/usb usbfs rw,nosuid,nodev,noexec 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
devpts /dev/pts devpts rw,nosuid,noexec,gid=5,mode=620 0 0
fusectl /sys/fs/fuse/connections fusectl rw 0 0
/dev/dm-2 /mnt/big ext3 rw,errors=remount-ro,data=ordered,jqfmt=vfsv0,usrjquota=aquota.user 0 0

ensuite

parsley:/mnt# fuser -vm /mnt/big/
parsley:/mnt# lsof +D big
parsley:/mnt# umount -f /mnt/big/
umount2: Device or resource busy
umount: /mnt/big: device is busy
umount2: Device or resource busy
umount: /mnt/big: device is busy

parsley:/mnt# losetup -a    
/dev/loop0: [fd02]:59 (/mnt/big/dot-dropbox.ext2)
/dev/loop1: [fd02]:59 (/mnt/big/dot-dropbox.ext2)

parsley:/mnt# losetup -d /dev/loop0
parsley:/mnt# losetup -d /dev/loop1
parsley:/mnt# losetup -a
parsley:/mnt# umount big/
parsley:/mnt#

Un message sur le forum Gentoo répertorie également les fichiers d' échange en tant que coupable potentiel; Bien que la permutation de fichiers soit probablement assez rare de nos jours, il n’est pas inutile de vérifier le résultat de cat /proc/swaps. Je ne sais pas si les quotas pourraient empêcher un démontage - je me tenais à la paille.

ZakW
la source
12
La disponibilité de tous les 924 jours signifie que vous devez mettre à jour les correctifs de votre noyau :-)
w00t
+1 pour mentionner les fichiers d'échange, ils font le démontage de bloc, et sont à peu près indétectable si vous n'êtes pas les vérifier directement.
P.Péter le
22

Au lieu d'utiliser lsof pour explorer le système de fichiers, utilisez simplement la liste complète des fichiers ouverts et mettez-la à jour. Je trouve que cela retourne plus vite, même si c'est moins précis. Il devrait faire le travail.

lsof | grep '/path'
Caleb
la source
1
lsof / path ne regarde que par le chemin.
Ole Tange
7
Je n'ai pas dit lsof /path, j'ai dit lsof | grep '/path'. La différence est que lsof sans argument montre tous les fichiers ouverts en utilisant une sorte de table de cache, et que grep est très rapide dans sa recherche. Les choses que vous avez essayées avec lsof lui permettent de parcourir le système de fichiers, ce qui prend beaucoup de temps.
Caleb
1
Comme je le disais: lsof /pathregarde seulement le chemin. Il ne regarde pas chaque fichier. Il est souvent beaucoup plus rapide que lsof | grep /path(dans mon test non scientifique, le YMMV était 20 fois plus rapide) car il ne regarde pas tous les fichiers ouverts, mais uniquement les fichiers de ce chemin.
Ole Tange
Je ne suis pas sûr de la différence technique, mais lorsqu’il a enquêté sur un montage NFS obsolète, il lsof /pathn’a rien donné , mais lsof | grep /pathil m’a montré le processus qui consistait à conserver des fichiers ouverts et à m’empêcher de démonter le volume.
dpw
20

Pour moi, le processus incriminé était un démon fonctionnant dans un chroot. Parce que c'était dans un chroot, lsofet fuserne le trouverais pas.

Si vous pensez qu'il reste quelque chose dans un chroot, sudo ls -l /proc/*/root | grep chroottrouvez le coupable (remplacez "chroot" par le chemin qui mène au chroot).

cibyr
la source
1
Nice, et sous FreeBSD, j'ai fait ceci: sudo ls -l /proc/*/status | grep HOSToù HOST est le nom d'hôte de la prison
JGurtz
1
Sur mon système (Mint Qiana) lsof /mountpointet les fuser /mountpointdeux trouvent un processus même s’ils sont chrootés.
Ole Tange
10

Ouvrir des fichiers

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

lsof +f -- <mountpoint or device>

Il y a un avantage à utiliser /dev/<device>plutôt que /mountpoint: un point de montage disparaît après un umount -lou peut être caché par un montage superposé.

fuserpeut également être utilisé, mais à mon avis lsofa une sortie plus utile. Cependant, il fuserest utile de tuer les processus qui causent vos drames afin que vous puissiez continuer votre vie.

Liste des fichiers sur <mountpoint>(voir l'avertissement ci-dessus):

fuser -vmM <mountpoint>

Ne coupez interactivement que les processus dont les fichiers sont ouverts à l'écriture:

fuser -vmMkiw <mountpoint>

Après avoir remonté read-only ( mount -o remount,ro <mountpoint>), il est prudent 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 d'essayer umountpose problème. Vérifier avec:

mount | grep <mountpoint>/

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

losetup -la

Inodes anonymes (Linux)

Les inodes anonymes peuvent être créés par:

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

Ce type de pokemon est le plus insaisissable et apparaît dans lsofla TYPEcolonne 's sous la forme a_inode(non documenté dans la lsofpage de manuel ).

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

lsof | grep a_inode

Pour plus d'informations sur les processus contenant des inodes anonymes, voir: Liste des surveillances inotify actuelles (nom du chemin, PID) .

Tom Hale
la source
5

Pour que l’unité de fusion affiche les PID avec un montage ouvert, vous devez utiliser -m

fuser -m /path
Patrick
la source
2
Vrai, mais non pertinent: lsof /pathfournit la même liste de PID que fuser -m /path.
Gilles
fuser -M /pathvérifiera s'il /paths'agit d'un point de montage.
user3804598
5

Nous avons un système propriétaire où le système de fichiers racine est normalement en lecture seule. Parfois, lorsque des fichiers doivent être copiés, il est remonté en lecture-écriture:

mount -oremount,rw /

Et ensuite remonté:

mount -oremount,ro /

Cette fois cependant, mountcontinue à donner l' mount: / is busyerreur. Cela était dû à un processus contenant un descripteur ouvert dans un fichier qui avait été remplacé par une commande exécutée lorsque le système de fichiers était en lecture-écriture. La ligne importante de la lsof -- /sortie se trouve être (les noms ont été changés):

replicate  1719 admin DEL REG 8,5  204394 /opt/gns/lib/replicate/modules/md_es.so

Notez le DELdans la sortie. Le simple redémarrage du processus en conservant le fichier supprimé a résolu le problème.

pdp
la source
3
Donc, le résumé est: processus ayant un fichier ouvert qui a été supprimé. Bonne entrée.
Ole Tange
4

lsofet fuserne m'a rien donné non plus.

Après avoir renommé tous les répertoires possibles en .old et redémarré le système chaque fois que j'ai apporté des modifications, j'ai trouvé un répertoire particulier (relatif à postfix) responsable.

Il s’est avéré que j’avais déjà créé un lien symbolique /var/spool/postfixvers /disk2/pers/mail/postfix/varspoolvers afin de minimiser les écritures sur disque sur un système de fichiers racine basé sur SDCARD (Sheeva Plug).

Avec ce lien symbolique, même après l' arrêt de la postfixet des dovecotservices ( à la fois ps aux, ainsi que netstat -tuanpne montrait rien lié) Je n'ai pas pu unmount /disk2/pers.

Lorsque j'ai supprimé le lien symbolique et mis à jour les fichiers postfixet dovecotconfig pour qu'ils pointent directement vers les nouveaux répertoires, /disk2/pers/j'ai pu arrêter avec succès les services et unmountle répertoire.

La prochaine fois, je regarderai de plus près le résultat de:

ls -lR /var | grep ^l | grep disk2

La commande ci-dessus listera de manière récursive tous les liens symboliques dans une arborescence de répertoires (commençant ici à /var) et filtrera les noms qui pointent vers un point de montage cible spécifique (ici disk2).

captcha
la source
3

J'avais ce problème et il s'est avéré qu'il y avait des sessions d'écran actives en arrière-plan que je ne connaissais pas. Je me suis connecté à l'autre session d'écran active et son shell n'était même pas encore dans le répertoire monté. Tuer ces autres sessions shell a résolu le problème pour moi.

Je pensais juste que je partagerais ma résolution.

colemanm
la source
1

Aujourd'hui, le problème était une socket ouverte (spécifiquement tmux):

mount /mnt/disk
export TMPDIR=/mnt/disk
tmux
<<detatch>>
umount /mnt/disk
umount: /mnt/disk: device is busy.
lsof | grep /mnt/disk
tmux      20885             root    6u     unix 0xffff880022346300        0t0    3215201 /mnt/disk/tmux-0/default
Ole Tange
la source
1

J'ai deux bindet overlaymonte sous ma monture qui ont été me bloquer, vérifier l'achèvement onglet pour le point de montage que vous voulez démonter. Je soupçonne que c’est la monture en superposition en particulier, mais elle aurait aussi pu être liée

ThorSummoner
la source
1

C'est plus une solution de contournement qu'une réponse, mais je la poste au cas où cela pourrait aider quelqu'un.

Dans mon cas, j'essayais de modifier LVM car je voulais agrandir la partition / var, donc je devais la démonter. J'ai essayé tous les commentés et répondu dans ce post (merci tout le monde et en particulier @ ole-tange pour les avoir rassemblés) et j'ai quand même eu l'erreur "device is busy".

J'ai aussi essayé de supprimer la plupart des processus dans l'ordre spécifié dans le niveau d'exécution 0, juste au cas où l'ordre serait pertinent dans mon cas, mais cela n'a pas aidé non plus. J'ai donc créé un niveau d'exécution personnalisé (combinant la sortie de chkconfig dans de nouvelles commandes chkconfig --level) qui serait très similaire à 1 (mode mono-utilisateur) mais avec des fonctionnalités réseau (avec ssh network et xinet).

Comme j'utilisais redhat, le niveau 4 est marqué "inutilisé / défini par l'utilisateur", donc je l'ai utilisé et je l'ai exécuté. init 4 Dans mon cas, cela a été correct car je devais redémarrer le serveur dans tous les cas, mais ce sera probablement le cas. de quiconque tordre les disques.

Gabriel Xunqueira
la source