Comment savoir quels processus empêchent le démontage d'un périphérique?

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

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

Utilisez lsof | grep /media/whateverpour savoir ce qui utilise la monture.

En outre, envisagez umount -l(laumount umount) pour empêcher de nouveaux processus d’utiliser le lecteur pendant le nettoyage.

La plupart du temps, la meilleure commande à utiliser est lsof ( « l i s t o pen f Iles »).

lsof +f -- /media/usb0

où /media/usb0est 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, tout seul, de sorte que cela lsof /media/usb0fonctionne également. Cela permet de trouver des fichiers ouverts (même non liés), des fichiers mappés en mémoire, des répertoires en cours et des utilisations plus obscures. Vous devez 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 qui lsofdoivent être exécutées en tant que root).

Il y a des utilisations que lsof ne trouvera pas; ceux-ci sont rares sur les supports amovibles. Ils incluent:

• points de montage: vous ne pouvez pas démonter /foos'il /foo/bars'agit d'un point de montage.
• Monter des périphériques: vous ne pouvez pas démonter /foos'il /foo/bars'agit d'un périphérique bloc monté ou d'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 pouvant servir dans un pincement est fuser, qui ne répertorie que les PID des processus avec des fichiers ouverts sur le périphérique:

fuser -m /media/usb0

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

fuser -Mk /mnt/path
umount /mnt/path

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 supprimez de manière interactive 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 umountcausera 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)

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

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 être suspendu pendant l' vx_softcnt_flush()appel. Le blocage se produit parce que les contrôles inotify incrémentent la i_countvariable et le v_os_hold valuemaintiennent élevés jusqu'à ce que l'observateur inotify libère le blocage.

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

Pour (au moins) OpenBSD:

$ fstat /mnt/mountpoint

Par exemple (utiliser doaspour exécuter en fstattant que root, sinon nous ne verrions 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/portsavant que l'utilisateur _pbuildn'ait fini d'exécuter ces deux makeprocessus.

C'est un piège courant: vous appelez un utilisateur différent (root ou tout autre utilisateur), accédez au répertoire d'un périphérique monté, puis vous vous déconnectez en tant qu'utilisateur. Lorsque vous oubliez que vous êtes parti dans ce répertoire, vous pouvez essayer de trouver jusqu'à ce que vous soyez aveugle. lsofne montre au shell que le répertoire en cours utilise ce périphérique. Vous voudrez peut-être utiliser à nouveau cet utilisateur pour modifier votre répertoire.