There are a lot of similar problems like "Device or resource busy". But I think my problem is different compared to them.
I use mount --bind to bind a directory:
mount --bind /tmp/origin /tmp/mount
And then I could unmount successfully:
umount /tmp/mount
And then if I call rm at once
rm -rf /tmp/mount
I could get a error Device or resource busy. If I wait 2~3 seconds, and then call rm, it could success.
So this behaviour is very strange here. I try to use
lsof +D /tmp/mount
But I could not see anything.
I also use fuser -vm /tmp/mount, but I could not see any process hold this folder.
I compare the /proc/mounts before umount /tmp/mount and after umount /tmp/mount. /tmp/mount has already been removed.
I compare the stat /proc/mounts before umount /tmp/mount and after umount /tmp/mount. The inode is also different; this means /tmp/mount has already removed complete.
Even if I call sync && echo 2 > /proc/sys/vm/drop_caches and try to drop file caches, it still does not work.
I try this in both Ubuntu 14.04 (Trusty Tahr) and CentOS 6.6. They have the same results.
Thank you for the gavv answer. But I found the result is another problem. We use the CLONE_NEWNS flag when fork a process. More details could be found in the CLONE_NEWNS flag and MESOS-3349 Device busy bug.
In a short word, we mount in the parent process. And then unmount in the child process. Because of CLONE_NEWNS, the mount point still exists, which is handled by the parent process. So when calling, it rmdir would get the EBUSY error code.
To avoid the above problems, we could use a shared mount or slave mount. More details could be found in LWN 159092.