it-swarm-fr.com

Comment surmonter «appareil ou ressource occupé»?

J'ai essayé de rm -rf un dossier et "périphérique ou ressource occupé".

Sous Windows, j'aurais utilisé LockHunter pour résoudre ce problème. Quel est l'équivalent Linux? (Veuillez donner comme réponse une méthode simple "déverrouiller ceci", et ne pas compléter des articles comme celui-ci . Bien qu'ils soient utiles, je suis actuellement intéressé par juste ASimpleMethodThatWorks ™)

250
ripper234

L'outil que vous voulez est lsof, qui signifie list open files.

Il a beaucoup d'options, alors consultez la page de manuel, mais si vous voulez voir tous les fichiers ouverts dans un répertoire:

lsof +D /path

Cela récurrera à travers le système de fichiers sous /path, Alors attention à le faire sur de grandes arborescences de répertoires.

Une fois que vous savez quels processus ont des fichiers ouverts, vous pouvez quitter ces applications ou les tuer avec la commande kill(1).

255
camh

parfois, c'est le résultat de problèmes de montage, donc je démonterais le système de fichiers ou le répertoire que vous essayez de supprimer:

umount/chemin

122
kip2

J'utilise fuser pour ce genre de chose. Il répertorie quel processus utilise un ou plusieurs fichiers dans un montage.

16
BillThor

Voici la solution:

  1. Allez dans le répertoire et tapez ls -a
  2. Vous trouverez un .xyz fichier
  3. vi .xyz et examinez le contenu du fichier
  4. ps -ef | grep username
  5. Vous verrez le contenu .xyz dans la 8e colonne (dernière ligne)
  6. kill -9 job_ids - où job_ids est la valeur de la 2e colonne du contenu d'erreur provoqué dans la 8e colonne
  7. Essayez maintenant de supprimer le dossier ou le fichier.
12
user73011

J'ai eu ce même problème, construit un one-liner commençant par la recommandation @camh:

lsof +D ./ | awk '{print $2}' | tail -n +2 | xargs kill -9

La commande awk saisit le PIDS. La commande tail supprime la première entrée embêtante: "PID". J'ai utilisé -9 lors de la mise à mort, d'autres pourraient avoir des options plus sûres.

9

J'expérimente cela fréquemment sur des serveurs qui ont des systèmes de fichiers réseau NFS. Je suppose que cela a quelque chose à voir avec le système de fichiers, car les fichiers sont généralement nommés comme .nfs000000123089abcxyz.

Ma solution typique consiste à renommer ou à déplacer le répertoire parent du fichier, puis à revenir plus tard dans un jour ou deux et le fichier aura été supprimé automatiquement, auquel cas je suis libre de supprimer le répertoire.

Cela se produit généralement dans les répertoires où j'installe ou compile des bibliothèques de logiciels.

7
user5359531

J'ai eu ce problème lorsqu'un test automatisé a créé un disque virtuel. Les commandes suggérées dans les autres réponses, lsof et fuser, n’ont pas aidé. Après les tests, j'ai essayé de le démonter puis de supprimer le dossier. J'étais vraiment confus pendant des siècles parce que je ne pouvais pas m'en débarrasser - je n'arrêtais pas d'obtenir "Appareil ou ressource occupé"!

Par accident, j'ai découvert comment me débarrasser d'un disque virtuel. J'ai dû le démonter le même nombre de fois que j'avais exécuté la commande mount, c'est-à-dire Sudo umount path

Étant donné qu'il a été créé à l'aide de tests automatisés, il a été monté plusieurs fois, d'où la raison pour laquelle je ne pouvais pas m'en débarrasser en le démontant simplement une fois après les tests. Donc, après l'avoir démonté manuellement plusieurs fois, il est finalement redevenu un dossier normal et j'ai pu le supprimer.

J'espère que cela peut aider quelqu'un d'autre qui rencontre ce problème!

5
gloriphobia

En partant de la question de Prabhat ci-dessus, j'ai eu ce problème dans macos High Sierra lorsque j'ai échoué un processus encfs, le redémarrage l'a résolu, mais cela

ps -ef | grep name-of-busy-dir

M'a montré le processus et le PID (colonne deux).

Sudo kill -15 pid-here

l'a corrigé.

5
bil

Si le serveur est accessible, essayez

Suppression de ce répertoire du serveur

Ou, faites mount et mount à nouveau, essayez umount -l: umount paresseux en cas de problème avec umount normal.

Moi aussi, j'ai eu ce problème où

lsof +D path: ne donne aucune sortie

ps -ef: ne donne aucune information pertinente

3