web-dev-qa-db-fra.com

Comment savoir quels processus empêchent le démontage d'un appareil?

Parfois, je voudrais démonter un périphérique USB avec umount /run/media/theDrive, mais je reçois un drive is busy Erreur.

Comment savoir quels processus ou programmes accèdent à l'appareil?

processopen-filesunmounting
70
Stefan

Utilisation lsof | grep /media/whatever pour découvrir ce qui utilise la monture.

Considérez également umount -l (umount paresseux) pour empêcher de nouveaux processus d'utiliser le lecteur pendant le nettoyage.

70
Peter Eisentraut

La plupart du temps, la meilleure commande à utiliser est lsof (“ l i s t o stylo f iles ”).

lsof +f -- /media/usb0

où /media/usb0 est le point de montage du lecteur USB ou d'un autre système de fichiers à démonter. +f -- indique à lsof de traiter l'argument suivant comme un point de montage; il gère généralement, mais pas toujours, de manière autonome, de sorte que lsof /media/usb0 fonctionne également. Cela trouve les fichiers ouverts (même ceux qui ne sont pas liés), les fichiers mappés en mémoire, les répertoires actuels et certaines utilisations plus obscures. Vous devrez exécuter la commande en tant que root pour obtenir des informations sur les processus des autres utilisateurs (et je pense qu'il existe des unités où lsof doit être exécuté en tant que root).

Il existe des utilisations que lsof ne trouvera pas; ce sont rares sur les supports amovibles. Ils comprennent:

  • points de montage: vous ne pouvez pas démonter /foo si /foo/bar est un point de montage.
  • monter des périphériques: vous ne pouvez pas démonter /foo si /foo/bar est un périphérique de bloc monté ou un fichier normal monté en boucle, ou s'il est la source d'un montage de liaison Linux.
  • Exportation NFS: lsof ne détectera pas qu'une arborescence est exportée par un serveur NFS du noyau.

Une autre commande qui peut servir à la rigueur est la fusion, qui répertorie uniquement les PID des processus avec des fichiers ouverts sur l'appareil:

fuser -m /media/usb0
37
Gilles 'SO- stop being evil'

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 montage 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 avoir remonté 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 ( merci Stephen Kitt ), 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 (Qui n'est pas documenté dans la page man 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) .

inotify montres (Linux)

Ce commentaire explique pourquoi inotify ne devrait pas empêcher un démontage, mais cette note décrit les situations dans lesquelles il va :

un démontage peut se bloquer dans l'appel vx_softcnt_flush(). Le blocage se produit car les montres inotify incrémentent la variable i_count Et font en sorte que v_os_hold value Reste élevé jusqu'à ce que l'observateur inotify relâche la suspension.

9
Tom Hale

Vous pouvez utiliser lsof comme Peter l'a dit, ou si vous êtes sûr de vouloir tuer toutes ces choses et les démonter, vous pouvez probablement faire quelque chose comme:

fuser -Mk /mnt/path
umount /mnt/path
8
pioto

Si vous utilisez GNOME, le démontage via Nautilus affichera un message indiquant quel processus utilise toujours le lecteur et le fichier qu'il utilise.

alt text

5
tshepang

Pour (au moins) OpenBSD:

$ fstat /mnt/mountpoint

Par exemple (en utilisant doas pour exécuter fstat en tant que root car nous ne verrions autrement que nos propres processus):

$ doas fstat /usr/ports
USER     CMD          PID   FD MOUNT        INUM MODE         R/W    SZ|DV NAME
_pbuild  make       15172   wd /usr/ports  3923598  drwxrwxr-x     r     1536 /usr/ports/
_pbuild  make       40034   wd /usr/ports  3923598  drwxrwxr-x     r     1536 /usr/ports/

Dans ce cas, je ne pourrais pas démonter /usr/ports jusqu'à ce que l'utilisateur _pbuild avait fini d'exécuter ces deux processus make.

1
Kusalananda