rmdir fehlgeschlagen, weil Gerät oder Ressource ausgelastet ist

Ich hatte ein solches Problem, weil ich freigegebene Ordner in VM mounte und das Verzeichnis nach dem Unmounten entfernen möchte und ich nur meine Lösung freigeben möchte.

1. Unmount-Pfad

   sudo umount /your_path
   

2. mout-Pfad in /etc/fstab entfernen

   sudo nano /etc/fstab
   

3. Neustart

   sudo reboot
   

4. Verzeichnis entfernen

   sudo rm -rf /your_path
   

Vielen Dank für die Antwort von @g-v. Aber ich fand das Ergebnis ist ein weiteres Problem. Wir verwenden das Flag CLONE_NEWNS, wenn wir einen Prozess forken. Weitere Details finden Sie im CLONE_NEWNS-Flag und im MESOS-3349-Fehler „Gerät ausgelastet“

Kurz gesagt, wir montieren den übergeordneten Prozess. Und dann umount im untergeordneten Prozess, wegen CLONE_NEWNS, existiert immer noch der Einhängepunkt, der vom übergeordneten Prozess gehandhabt wird. Beim Aufruf würde rmdir also einen EBUSY-Fehlercode erhalten.

Um die oben genannten Probleme zu vermeiden, könnten wir Shared Mount oder Slave Mount verwenden. Weitere Details finden Sie in LWN 159092

Meiner Erfahrung nach sind die folgenden Operationen unter Linux asynchron:

• Datei wird geschlossen. Unmittelbar nach close() gibt zurück, umount() kann EBUSY zurückgeben während es eine asynchrone Freigabe durchführt. Siehe Diskussion hier:Seite 1, Seite 2.
• Umounten des Dateisystems. Das bereitgestellte Gerät ist möglicherweise beschäftigt, bis alle Daten auf die Festplatte geschrieben wurden.

Sogar ich rufe sync && echo 2 > /proc/sys/vm/drop_caches an und versuchen, Datei-Caches zu löschen, es funktioniert immer noch nicht.

Siehe sync(8) :

Unter Linux sync ist nur garantiert, die Dirty-Blöcke zum Schreiben einzuplanen; es kann tatsächlich eine kurze Zeit dauern, bis alle Blöcke endgültig geschrieben sind. Die reboot(8) und halt(8) Befehle berücksichtigen dies, indem sie nach dem Aufruf von sync(2) einige Sekunden schlafen .

Wie bei /proc/sys/vm/drop_caches , siehe hier:

Dies ist ein zerstörungsfreier Vorgang und befreit keine schmutzigen Objekte.

Daher können unmittelbar nach Ihrem Befehl noch Daten zum Schreiben in die Warteschlange gestellt werden und das Aushängen ist noch nicht abgeschlossen.

Aktualisieren

Wenn jedoch asynchrones Aushängen in Aktion ist, gibt der Kernel EBUSY zurück für Operationen auf gemounteten Geräten , aber nicht für Einhängepunkt .

Die oben genannten Fälle konnten das also nicht der Grund für dein Problem sein :P

PS.

Eigentlich verstehe ich nicht, warum die Manpage besagt, dass sync(8) ist unter Linux nicht synchron. Es ruft sync(2) auf was besagt:

Gemäß der Standardspezifikation (z. B. POSIX.1-2001), sync() plant die Schreibvorgänge, kann aber zurückkehren, bevor das eigentliche Schreiben abgeschlossen ist. Seit Version 1.3.20 Linux wartet jedoch tatsächlich. (Dies garantiert immer noch keine Datenintegrität:Moderne Festplatten haben große Caches.)