rmdir gagal karena Perangkat atau sumber daya sibuk

Saya menghadapi masalah seperti ini karena saya me-mount folder bersama di VM dan saya ingin menghapus direktori setelah unmount dan saya hanya ingin membagikan solusi saya.

1. un-mount path

   sudo umount /your_path
   

2. hapus jalur mout di /etc/fstab

   sudo nano /etc/fstab
   

3. mulai ulang

   sudo reboot
   

4. hapus direktori

   sudo rm -rf /your_path
   

Terima kasih atas jawaban @g-v. Tapi saya menemukan hasilnya adalah masalah lain. Kami menggunakan flag CLONE_NEWNS saat melakukan proses fork. Detail lebih lanjut dapat ditemukan di bendera CLONE_NEWNS dan MESOS-3349 Device busy bug

Singkatnya, kami memasang proses induk. Dan kemudian umount dalam proses anak, karena CLONE_NEWNS, titik mount masih ada yang ditangani oleh proses induk. Jadi saat memanggil rmdir akan mendapat kode kesalahan EBUSY.

Untuk menghindari masalah di atas, kita bisa menggunakan shared mount atau slave mount. Detail lebih lanjut dapat ditemukan di LWN 159092

Menurut pengalaman saya, operasi berikut tidak sinkron di Linux:

• Menutup berkas. Segera setelah close() kembali, umount() dapat mengembalikan EBUSY saat melakukan rilis asinkron. Lihat pembahasannya di sini:halaman 1, halaman 2.
• Meng-mount sistem file. Perangkat terpasang mungkin sedang sibuk hingga semua data ditulis ke disk.

Bahkan saya sebut sync && echo 2 > /proc/sys/vm/drop_caches dan mencoba membuang cache file, tetap tidak berhasil.

Lihat sync(8) :

Di Linux, sync hanya dijamin untuk menjadwalkan blok kotor untuk menulis; sebenarnya bisa memakan waktu singkat sebelum semua blok akhirnya ditulis. reboot(8) dan halt(8) perintah memperhitungkan ini dengan tidur selama beberapa detik setelah memanggil sync(2) .

Adapun /proc/sys/vm/drop_caches , lihat di sini:

Ini adalah operasi non-destruktif dan tidak akan membebaskan objek kotor apa pun.

Jadi, segera setelah perintah Anda, data mungkin masih dalam antrean untuk penulisan dan umount belum selesai.

Perbarui

Namun, saat umounting asinkron sedang beraksi, kernel akan mengembalikan EBUSY untuk operasi pada perangkat terpasang , tetapi tidak untuk mount point .

Jadi kasus di atas tidak bisa menjadi alasan masalah Anda :P

PS.

Sebenarnya saya tidak mengerti mengapa halaman manual menyatakan bahwa sync(8) tidak sinkron di Linux. Itu memanggil sync(2) yang menyatakan:

Menurut spesifikasi standar (misalnya, POSIX.1-2001), sync() menjadwalkan penulisan, tetapi dapat kembali sebelum penulisan sebenarnya selesai. Namun, sejak versi 1.3.20 Linux sebenarnya menunggu. (Ini masih tidak menjamin integritas data:disk modern memiliki cache yang besar.)