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

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é?

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

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.

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'

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).

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) .

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

fuser -m /path

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.

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).

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.

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

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

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.