rmdir non riuscito a causa del dispositivo o della risorsa occupata

Ho riscontrato un problema come questo perché monto la cartella condivisa nella VM e voglio rimuovere la directory dopo lo smontaggio e voglio solo condividere la mia soluzione.

1. percorso di smontaggio

   sudo umount /your_path
   

2. rimuovere il percorso mout in /etc/fstab

   sudo nano /etc/fstab
   

3. riavvia

   sudo reboot
   

4. rimuovere la cartella

   sudo rm -rf /your_path
   

Grazie per la risposta di @g-v. Ma ho scoperto che il risultato è un altro problema. Usiamo il flag CLONE_NEWNS durante il fork di un processo. Ulteriori dettagli possono essere trovati nel flag CLONE_NEWNS e nel bug MESOS-3349 Device busy

In breve, montiamo nel processo genitore. E poi smontare nel processo figlio, a causa di CLONE_NEWNS, esiste ancora il punto di montaggio gestito dal processo padre. Quindi, quando la chiamata rmdir otterrebbe il codice di errore EBUSY.

Per evitare i problemi di cui sopra, potremmo usare il montaggio condiviso o il montaggio slave. Maggiori dettagli possono essere trovati in LWN 159092

Nella mia esperienza, le seguenti operazioni sono asincrone su Linux:

• File di chiusura. Subito dopo close() restituisce, umount() potrebbe restituire EBUSY mentre esegue il rilascio asincrono. Vedi la discussione qui:pagina 1, pagina 2.
• Smontaggio del filesystem. Il dispositivo montato potrebbe essere occupato finché tutti i dati non vengono scritti su disco.

Anche io chiamo sync && echo 2 > /proc/sys/vm/drop_caches e prova a eliminare le cache dei file, continua a non funzionare.

Vedi sync(8) :

Su Linux, sync è garantito solo per programmare i blocchi sporchi per la scrittura; in realtà può volerci un po' di tempo prima che tutti i blocchi vengano finalmente scritti. Il reboot(8) e halt(8) i comandi tengono conto di ciò dormendo per alcuni secondi dopo aver chiamato sync(2) .

Per quanto riguarda /proc/sys/vm/drop_caches , vedi qui:

Questa è un'operazione non distruttiva e non libererà alcun oggetto sporco.

Pertanto, subito dopo il tuo comando, i dati potrebbero essere ancora in coda per la scrittura e lo smontaggio non è ancora terminato.

Aggiorna

Tuttavia, quando lo smontaggio asincrono è in azione, il kernel restituirà EBUSY per le operazioni sul dispositivo montato , ma non per il punto di montaggio .

Quindi i casi di cui sopra non potevano sii la ragione del tuo problema :P

PS.

In realtà non capisco perché la pagina man affermi che sync(8) non è sincrono in Linux. Chiama sync(2) che afferma:

Secondo la specifica standard (ad esempio, POSIX.1-2001), sync() pianifica le scritture, ma può tornare prima che la scrittura effettiva sia terminata. Tuttavia, a partire dalla versione 1.3.20 Linux effettivamente aspetta. (Ciò non garantisce ancora l'integrità dei dati:i dischi moderni hanno cache di grandi dimensioni.)