umount: l'appareil est occupé. Pourquoi?
Lors de l'exécution umount /path Je reçois:
umount: /path: device is busy.
Le système de fichiers est énorme, donc lsof +D /path n'est pas une option réaliste.
lsof /path, lsof +f -- /path, et fuser /path tous ne renvoient rien. fuser -v /path donne:
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 -l et umount -f n'est pas assez bon pour ma situation.
Comment savoir pourquoi le noyau pense que ce système de fichiers est occupé?
Il semble que la cause de mon problème était le nfs-kernel-server exportait le répertoire. Le nfs-kernel-server va probablement derrière les fichiers ouverts normaux et n'est donc pas répertorié par lsof et fuser.
Quand j'ai arrêté le nfs-kernel-server Je pourrais umount le répertoire.
J'ai fait une page avec des exemples de toutes les solutions jusqu'à présent ici: http://oletange.blogspot.com/2012/04/umount-device-is-busy-why.html
Pour ajouter à BruceCrancommentaire ci-dessus, la cause de ma manifestation de ce problème était tout à l'heure un périmé montage en boucle. J'avais déjà vérifié la sortie de fuser -vm <mountpoint>/lsof +D <mountpoint>, mount et cat /proc/mounts, vérifié si certains anciens serveurs nfs-kernel-server étaient en cours d'exécution, désactivé les quotas, tenté (mais échoué) un umount -f <mountpoint> et je me suis résigné à abandonner 924 jours de disponibilité avant de finalement vérifier la sortie de losetup et trouver deux bouclages configurés mais non montés périmé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
puis
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#
A Gentoo forum post répertorie également les fichiers d'échange comme un coupable potentiel; bien que l'échange vers des fichiers soit probablement assez rare de nos jours, cela ne peut pas nuire de vérifier la sortie de cat /proc/swaps. Je ne sais pas si les quotas pourraient jamais empêcher un démontage - je m'accrochais aux pailles.
Au lieu d'utiliser lsof pour parcourir le système de fichiers, utilisez simplement la liste totale des fichiers ouverts et grepez-la. Je trouve que ce retour doit être plus rapide, bien qu'il soit moins précis. Cela devrait faire le travail.
lsof | grep '/path'
Pour moi, le processus offensant était un démon exécuté dans un chroot. Parce qu'il était dans un chroot, lsof et fuser ne le trouverait pas.
Si vous pensez qu'il vous reste quelque chose en cours d'exécution dans un chroot, Sudo ls -l /proc/*/root | grep chroot trouvera le coupable (remplacez "chroot" par le chemin d'accès au chroot).
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 (
openavecO_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) .
Pour que l'unité de fusion signale les PID tenant un support 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, ils sont remontés en lecture-écriture:
mount -oremount,rw /
Et puis remonté:
mount -oremount,ro /
Cette fois cependant, mount a continué à donner le mount: / is busy Erreur. Cela était dû à un processus contenant un descripteur ouvert dans un fichier qui avait été remplacé par une commande, qui a été exécutée lorsque le système de fichiers était en lecture-écriture. La ligne importante de lsof -- / la sortie se trouve être (les noms ont été modifiés):
replicate 1719 admin DEL REG 8,5 204394 /opt/gns/lib/replicate/modules/md_es.so
Notez le DEL dans la sortie. Le simple redémarrage du processus de conservation du fichier supprimé a résolu le problème.
lsof et fuser ne m'ont rien donné non plus.
Après avoir renommé tous les répertoires possibles en .old et redémarré le système à chaque fois après avoir apporté des modifications, j'ai trouvé un répertoire particulier (lié à postfix) qui était responsable.
Il s'est avéré que j'avais déjà créé un lien symbolique à partir de /var/spool/postfix à /disk2/pers/mail/postfix/varspool 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 des services postfix et dovecot (les deux ps aux aussi bien que netstat -tuanp n'a rien montré de connexe) Je n'ai pas pu unmount /disk2/pers.
Lorsque j'ai supprimé le lien symbolique et mis à jour les fichiers de configuration postfix et dovecot pour pointer directement vers les nouveaux répertoires sur /disk2/pers/ J'ai pu arrêter les services et unmount le répertoire.
La prochaine fois, j'examinerai de plus près la sortie de:
ls -lR /var | grep ^l | grep disk2
La commande ci-dessus listera récursivement tous les liens symboliques dans une arborescence de répertoires (commençant ici à /var) et filtrer les noms qui pointent vers un point de montage cible spécifique (ici disk2).
J'ai eu 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 actuellement assis dans le répertoire monté. Tuer ces autres sessions Shell a résolu le problème pour moi.
Je pensais juste partager ma résolution.
J'ai quelques montures bind et overlay sous ma monture qui me bloquaient, vérifiez la complétion de l'onglet pour le point de montage que vous souhaitez démonter. Je soupçonne que c'était le support de superposition en particulier, mais cela pourrait aussi être le lien
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 le LVM car je voulais agrandir la partition/var, donc je devais la démonter. J'ai essayé tous les commentaires et répondu dans ce post (merci à tous et surtout à @ ole-tange pour les avoir rassemblés) et j'ai toujours l'erreur "l'appareil est occupé".
J'ai également essayé de tuer la plupart des processus dans l'ordre spécifié dans le niveau d'exécution 0, juste au cas où l'ordre était pertinent dans mon cas, mais cela n'a pas aidé non plus. Donc, ce que j'ai fait, c'est de me créer un niveau d'exécution personnalisé (combinant la sortie de chkconfig dans de nouvelles commandes chkconfig --level) qui serait très similaire à 1 (mode utilisateur unique) mais avec des capacités réseau (avec ssh network et xinet).
Comme j'utilisais redhat, le niveau d'exécution 4 est marqué comme "inutilisé/défini par l'utilisateur", j'ai donc utilisé celui-ci et exécuté init 4 Dans mon cas, c'était correct car j'avais besoin de redémarrer le serveur dans tous les cas, mais ce sera probablement le cas de quiconque peaufinera les disques.
Aujourd'hui, le problème était un socket ouvert (en particulier 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