rmdir a échoué en raison d'un périphérique ou d'une ressource occupés

J'ai rencontré un problème comme celui-ci parce que je monte le dossier partagé dans la machine virtuelle et je veux supprimer le répertoire après le démontage et je veux juste partager ma solution.

1. chemin de démontage

   sudo umount /your_path
   

2. supprimer le chemin mout dans /etc/fstab

   sudo nano /etc/fstab
   

3. redémarrer

   sudo reboot
   

4. supprimer le répertoire

   sudo rm -rf /your_path
   

Merci pour la réponse @g-v. Mais j'ai trouvé le résultat est un autre problème. Nous utilisons l'indicateur CLONE_NEWNS lors du fork d'un processus. Plus de détails peuvent être trouvés dans l'indicateur CLONE_NEWNS et le bogue d'occupation de l'appareil MESOS-3349

En un mot, on monte en processus parent. Et puis umount dans le processus enfant, à cause de CLONE_NEWNS, le point de montage existe toujours et est géré par le processus parent. Ainsi, lorsque l'appel rmdir obtiendrait le code d'erreur EBUSY.

Pour éviter les problèmes ci-dessus, nous pourrions utiliser un montage partagé ou un montage esclave. Plus de détails peuvent être trouvés dans LWN 159092

D'après mon expérience, les opérations suivantes sont asynchrones sous Linux :

• Fermer le dossier. Immédiatement après close() renvoie, umount() peut retourner EBUSY pendant qu'il effectue une libération asynchrone. Voir la discussion ici :page 1, page 2.
• Suppression du système de fichiers. L'appareil monté peut être occupé jusqu'à ce que toutes les données soient écrites sur le disque.

Même moi j'appelle sync && echo 2 > /proc/sys/vm/drop_caches et essayez de supprimer les caches de fichiers, cela ne fonctionne toujours pas.

Voir sync(8) :

Sous Linux, sync est seulement garanti de programmer les blocs modifiés pour l'écriture ; cela peut en fait prendre un peu de temps avant que tous les blocs ne soient finalement écrits. Le reboot(8) et halt(8) les commandes en tiennent compte en dormant quelques secondes après avoir appelé sync(2) .

Comme pour /proc/sys/vm/drop_caches , voir ici :

Il s'agit d'une opération non destructive et ne libérera aucun objet sale.

Ainsi, immédiatement après votre commande, les données peuvent encore être en attente d'écriture et le démontage n'est pas encore terminé.

Mettre à jour

Cependant, lorsque le démontage asynchrone est en action, le noyau renverra EBUSY pour les opérations sur appareil monté , mais pas pour le point de montage .

Ainsi, les cas ci-dessus ne pourraient pas être la raison de votre problème :P

PS.

En fait, je ne comprends pas pourquoi la page de manuel indique que sync(8) n'est pas synchrone sous Linux. Il appelle sync(2) qui indique :

Selon la spécification standard (par exemple, POSIX.1-2001), sync() planifie les écritures, mais peut revenir avant que l'écriture proprement dite ne soit terminée. Cependant, depuis la version 1.3.20, Linux attend en fait. (Cela ne garantit toujours pas l'intégrité des données :les disques modernes ont de grands caches.)