Come superare "dispositivo o risorsa occupata"?


229

Ho provato a rm -rfuna cartella e ho ottenuto "dispositivo o risorsa occupata".

In Windows, avrei usato LockHunter per risolvere questo problema. Qual è l'equivalente di Linux? (Per favore, dai come risposta un semplice metodo di "sblocco" e non articoli completi come questo . Sebbene siano utili, al momento sono interessato solo a ASimpleMethodThatWorks ™)


5
Grazie, mi è stato utile - venivo da Linux a Windows, cercavo l'equivalente di lsof - LockHunter.
Sonia Hamilton,

3
Che diavolo? Unix non ti impedisce di cancellare file aperti come fa Windows. Questo è il motivo per cui è possibile eliminare l'intero sistema eseguendo rm -rf /... eliminerà felicemente ogni singolo file, incluso / bin / rm.
psusi,

1
@psusi, non è corretto. O hai una cattiva fonte di informazioni o stai solo inventando qualcosa. Linux, come Windows, ha il blocco di file e dispositivi. È un po 'rotto, però. 0pointer.de/blog/projects/locking.html
foobaremade

1
@foobaremade, normalmente quelli sono solo blocchi di avviso e la pagina man sembra indicare che sono solo per leggere / scrivere, non per scollegare.
psusi,

Risposte:


232

Lo strumento che vuoi è lsof, che sta per elenco di file aperti .

Ha molte opzioni, quindi controlla la pagina man, ma se vuoi vedere tutti i file aperti in una directory:

lsof +D /path

Ciò si ripercuoterà attraverso il filesystem sotto /path, quindi attenzione a farlo su grandi alberi di directory.

Una volta che sai quali processi hanno file aperti, puoi uscire da quelle app o ucciderle con il kill(1)comando.


46
E se non ci fossero risultati?
Marines

22
@marines: controlla se un altro filesystem è montato sotto /path. Questa è una causa di "file aperti" nascosti.
Camh,

2
Il comando lsof direttamente sul percorso non funziona. Quindi, in pratica, è necessario andare nella posizione del percorso ed eseguire lsof busy_file, quindi terminare tutto il processo
J4cK,

4
lsofsembra non fare nulla per me: lsof storage/logs/laravel.lognon ha restituito nulla, e così ha fatto lsof +D storage/logs/. umountrispose con not mounted.
Ryan,

1
Solo per approfondire la risposta di @camh: Usa mount | grep <path>. Ciò dimostra che qualsiasi /dev/<abc>potrebbe essere montato sul <path>. Utilizzare sudo umount -lf /dev/<abc>e quindi provare a rimuovere <path>. Per me va bene. Grazie @camh
Vikas Goel,

107

a volte è il risultato di problemi di montaggio, quindi smonterei il filesystem o la directory che stai cercando di rimuovere:

umount / path


5
Sono le quattro meno un quarto. Grazie amico, mi hai salvato la notte. Divertente. Sulla linea singola - così tanto tempo sprecato -.- '
Aiyion.Prime

1
il mio problema era una directory di registro montata come / dev / mapper / vg00-root
Spikolynn il

1
Mi ha aiutato a uscire da una marmellata simile sugli avvolgitori.
Jon,

1
nel mio caso, Jenkins non ha
smontato la directory

1
nel mio caso, smontare con il desktop Ubuntu ha funzionato !! Grazie
JRichardsz,

14

Uso fuserper questo genere di cose. Elencherà quale processo sta usando un file o file all'interno di un mount.


fuseraiuta solo nel caso specifico in cui si desidera smontare un filesystem. Qui il problema è trovare cosa sta usando un file specifico.
Gilles,

@Gilles: funziona anche per i file.
BillThor,

Spiacente, obiezione errata: fusernon aiuta qui perché il problema è trovare tutti i file aperti in un albero di directory. Puoi dire lsofdi mostrare tutti i file e i filtri o di farlo ricorrere; fusernon ha tale modalità e deve essere invocato su ogni file.
Gilles,

@Giles: fuserelenchi delle opere. Prova fuser /var/log/*, se qualche registro è aperto, dirà quali e chi lo ha aperto. Se un semplice jolly, non funziona, findcon o senza xargsfarà il lavoro.
BillThor,

1
lsofnon era nel mio percorso mentre lo fuserero, permettendomi di trovare l'ID del processo offensivo da uccidere, quindi + 1 + grazie.
Stevesliva,

12

Ecco la soluzione:

  1. Vai nella directory e digita ls -a
  2. Troverai un .xyzfile
  3. vi .xyz e guarda qual è il contenuto del file
  4. ps -ef | grep username
  5. Vedrai il contenuto .xyz nell'ottava colonna (ultima riga)
  6. kill -9 job_ids - dove job_ids è il valore della seconda colonna dell'errore corrispondente causato contenuto nell'ottava colonna
  7. Ora prova a eliminare la cartella o il file.

4
Sarebbe interessante sapere da dove provengono quei file misteriosi.
John WH Smith,

9

Ho avuto lo stesso problema, ho creato un one-liner a partire dalla raccomandazione di @camh:

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

Il awkcomando prende i PIDS. Il tailcomando elimina la fastidiosa prima voce: "PID". Ho usato -9per uccidere, altri potrebbero avere opzioni più sicure.


1
Per renderlo più universale è possibile utilizzare ./ per la directory corrente anziché il log /
user2589273

Buon punto, @ user2589273. Aggiornato.
Choylton B. Higginbottom,

5

Ho avuto questo problema quando un test automatico ha creato un ramdisk. I comandi suggeriti nelle altre risposte, lsofe fuser, non sono stati di alcun aiuto. Dopo i test ho provato a smontarlo e quindi eliminare la cartella. Sono stato davvero confuso per anni perché non riuscivo a liberarmene - continuavo a ottenere "Dispositivo o risorsa occupata" !

Per caso ho scoperto come liberarmi di un ramdisk. Ho dovuto smontarlo lo stesso numero di volte in cui avevo eseguito il mountcomando, ad es sudo umount path

A causa del fatto che è stato creato utilizzando test automatici, è stato montato molte volte, quindi perché non riuscivo a liberarmene semplicemente smontandolo una volta dopo i test. Quindi, dopo averlo smontato manualmente molte volte, alla fine è diventato di nuovo una cartella normale e ho potuto eliminarlo.

Spero che questo possa aiutare qualcun altro che incontra questo problema!


5

Lo provo spesso su server che hanno file system di rete NFS. Suppongo che abbia qualcosa a che fare con il filesystem, dato che i file in genere hanno un nome simile .nfs000000123089abcxyz.

La mia soluzione tipica è quella di rinominare o spostare la directory principale del file, quindi tornare più tardi tra un giorno o due e il file sarà rimosso automaticamente, a quel punto sono libero di eliminare la directory.

Questo in genere accade nelle directory in cui sto installando o compilando librerie software.


4

Sfogliando la domanda di Prabhat sopra, ho avuto questo problema in macos high sierra quando ho bloccato un processo encfs, il riavvio lo ha risolto, ma questo

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

Mi ha mostrato il processo e il PID (colonna due).

sudo kill -15 pid-here

aggiustato.


Questo ha funzionato anche per me. Qual è il -15?
O.rka,

3

Se il server è accessibile, provare

Eliminazione di quella directory dal server

Oppure, fai umount e monta di nuovo, prova umount -l: umount pigro se stai affrontando un problema su umount normale.

Anch'io ho avuto questo problema dove

lsof +D path : non fornisce output

ps -ef : non fornisce informazioni pertinenti

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.