Comment surmonter “périphérique ou ressource occupé”?

229

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

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

files lock

— ripper234
source

5

Merci c'était pratique - je venais de Linux à Windows, cherchais l'équivalent de lsof - LockHunter.

— Sonia Hamilton

3

Que se passe-t-il? Unix ne pas vous empêcher de supprimer les fichiers ouverts comme le fait de Windows. C'est pourquoi vous pouvez supprimer tout votre système en exécutant rm -rf /... il supprimera tous les fichiers, y compris / bin / rm.

— Psusi

1

@ psusi, c'est inexact. Vous avez soit une mauvaise source d’information, soit vous inventez des choses. Linux, comme Windows, a le verrouillage de fichiers et de périphériques. C'est un peu cassé, cependant. 0pointer.de/blog/projects/locking.html

— foobarbecue

1

@foobarbecue, normalement ce ne sont que des verrous consultatifs et la page de manuel semble au moins indiquer qu’ils sont uniquement destinés à la lecture / écriture et non à des liens non liés.

— Psusi

232

L'outil que vous voulez est lsof, ce qui signifie ouvrir les fichiers de la liste .

Consultez la page de manuel, mais si vous voulez voir tous les fichiers ouverts dans un répertoire:

lsof +D /path

Cela se répètera à travers le système de fichiers sous /path, alors méfiez-vous-le sur les grandes arborescences.

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

— camh
source

46

Et s'il n'y avait pas de résultats?

— marines

22

@marines: Vérifie si un autre système de fichiers est monté en dessous /path. C'est une des causes des "fichiers ouverts" cachés.

— camh

2

La commande lsof directement sur le chemin ne fonctionne pas. Donc, fondamentalement, il faut aller dans le chemin, puis exécuter lsof busy_file puis tuer tout le processus

— J4cK

4

lsofsemble ne rien faire pour moi: lsof storage/logs/laravel.logrien renvoyé, et ainsi lsof +D storage/logs/. umounta répondu avec not mounted.

— Ryan

1

Juste pour élaborer sur @camh répondre: Utilisez mount | grep <path>. Cela montre que tout /dev/<abc>peut être monté sur le <path>. Utilisez sudo umount -lf /dev/<abc>et puis essayez de supprimer <path>. Travaille pour moi. Merci @camh

— Vikas Goel

107

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

umount / chemin

— kip2
source

5

Il est quatre heures moins le quart. Merci mec, tu as sauvé ma nuit. Hilarant. Sur une seule ligne - tellement de temps perdu -.- '

— Aiyion.Prime

1

mon problème était un répertoire de journal monté en tant que / dev / mapper / vg00-root

— Spikolynn

1

M'a aidé à sortir d'un bourrage similaire sur les bobiniers.

— Jon

1

dans mon cas, Jenkins n'a pas

— démonté

1

dans mon cas, démonter avec le bureau Ubuntu a fonctionné !! Merci

— JRichardsz

14

Je l'utilise fuserpour ce genre de chose. Il indiquera quel processus utilise un fichier ou des fichiers dans un montage.

— BillThor
source

fuseraide uniquement dans le cas spécifique où vous souhaitez démonter un système de fichiers. Ici, le problème est de trouver ce qui utilise un fichier spécifique.

— Gilles

@ Gilles: Fonctionne également pour les fichiers.

— BillThor

Désolé, objection erronée: cela fusern’aide pas ici car le problème est de trouver tous les fichiers ouverts dans une arborescence de répertoires. Vous pouvez dire lsofd’afficher tous les fichiers et les filtrer, ou bien de le rendre récurrent; fusern'a pas ce mode et doit être invoqué pour chaque fichier.

— Gilles le

@Giles: fuserlistes de travaux Essayez fuser /var/log/*, si des journaux sont ouverts, il indiquera lesquels et qui l'a ouvert. Si un simple caractère générique, ne fonctionnera pas, findavec ou sans xargsfera le travail.

— BillThor

1

lsofn’était pas sur mon chemin alors qu’il fuserme permettait de trouver l’ID de processus incriminé à tuer, donc + 1 + merci.

— Stevesliva

12

Voici la solution:

Allez dans le répertoire et tapez ls -a
Vous trouverez un .xyzfichier
vi .xyz et regarder dans quel est le contenu du fichier
ps -ef | grep username
Vous verrez le contenu .xyz dans la 8ème colonne (dernière ligne)
kill -9 job_ids - où job_ids est la valeur de la 2ème colonne du contenu correspondant à une erreur dans la 8ème colonne
Maintenant, essayez de supprimer le dossier ou le fichier.

— utilisateur73011
source

4

Il serait intéressant de savoir d’où viennent ces mystérieux fichiers.

— John WH Smith

9

J'ai eu ce même problème, construit une ligne commençant par @camh recommandation:

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

La awkcommande saisit le PIDS. La tailcommande supprime la première entrée embêtante: "PID". J'ai utilisé -9pour tuer, d'autres pourraient avoir des options plus sûres.

— Choylton B. Higginbottom
source

1

Pour le rendre plus universel, vous pouvez utiliser ./ pour le répertoire en cours au lieu de log /

— user2589273

Bon point, @ user2589273. Mis à jour.

— Choylton B. Higginbottom Le

5

J'ai eu ce problème quand un test automatisé a créé un disque virtuel. Les commandes suggérées dans les autres réponses lsofet ne fuserservaient à rien. Après les tests, j'ai essayé de le démonter, puis de supprimer le dossier. J'étais vraiment confus depuis 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 se débarrasser d'un disque mémoire. Je devais démonter le même nombre de fois que j'avais exécuté la mountcommande, à savoir sudo umount path

Du fait qu'il a été créé à l'aide de tests automatisés, il a été monté plusieurs fois, c'est pourquoi je ne pouvais pas m'en débarrasser en le démontant simplement une fois après les tests. Ainsi, après l'avoir démonté manuellement de nombreuses fois, il est finalement redevenu un dossier normal et je pouvais le supprimer.

Espérons que cela puisse aider quelqu'un d'autre qui rencontre ce problème!

— gloriphobie
source

5

Je rencontre souvent ce problème sur des serveurs dotés de 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 est de renommer ou de déplacer le répertoire parent du fichier, puis de revenir plus tard dans un jour ou deux et le fichier aura été supprimé automatiquement. À ce stade, je suis libre de supprimer le répertoire.

Cela se produit généralement dans des répertoires dans lesquels je suis en train d'installer ou de compiler des bibliothèques de logiciels.

— utilisateur5359531
source

4

Répondant à 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 ceci

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

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

sudo kill -15 pid-here

corrigé

— bil
source

Cela a fonctionné pour moi aussi. Quel est le -15?

— O.rka

3

Si le serveur est accessible, essayez

Supprimer ce répertoire du serveur

Ou bien, démontez et montez à nouveau, essayez umount -l: lazy umount si vous rencontrez un problème avec umount normal.

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

lsof +D path : ne donne pas de sortie

ps -ef : ne donne aucune information pertinente

— Prabhat Kumar Singh
source