4

I have a folder in /tmp that is mounted as ramfs. After some action that my script does, I delete everything inside said folder with the command:

rm -R -f "$tmp_dir"/{*,.*}

Then, I try to unmount the directory, but on the first try it doesn't work because the device is busy. After sleeping for a 0.5sec, the unmount succeeds.

I've verified that no process is using the folder or anything inside that folder with any of the following commands:

fuser -m "$tmp_dir" fuser "$tmp_dir" lsof +d "$tmp_dir" lsof "$tmp_dir"

Why would the device be busy in the 1st try?

Edit #1 (30 Sep, 18:32 UTC):
When I execute find "$tmp_dir" -delete, the unmount succeeds on the 1st time!
But then the find command complains about $tmp_dir being busy.

Edit #2 (30 Sep, 18:45 UTC):
With stat I noticed a change in the size of the folder, before an after the success in the unmount:

$ stat '/tmp/tmp.nbljlVcmix' File: `/tmp/tmp.nbljlVcmix' Size: 0 Blocks: 0 IO Block: 4096 directory Device: 17h/23d Inode: 121188 Links: 2 Access: (0700/drwx------) Uid: ( 1000/ dor) Gid: ( 0/ root) Access: 2013-09-30 20:37:51.430769893 +0300 Modify: 2013-09-30 20:37:51.430769893 +0300 Change: 2013-09-30 20:37:51.430769893 +0300 $ umount '/tmp/tmp.nbljlVcmix' umount: /tmp/tmp.nbljlVcmix: device is busy. (In some cases useful info about processes that use the device is found by lsof(8) or fuser(1)) $ sleep 0.5 $ umount '/tmp/tmp.nbljlVcmix' $ stat '/tmp/tmp.nbljlVcmix' File: `/tmp/tmp.nbljlVcmix' Size: 4096 Blocks: 8 IO Block: 4096 directory Device: 806h/2054d Inode: 2401825 Links: 2 Access: (0700/drwx------) Uid: ( 1000/ dor) Gid: ( 0/ root) Access: 2013-09-30 20:37:47.600513531 +0300 Modify: 2013-09-30 20:37:47.600513531 +0300 Change: 2013-09-30 20:37:47.610513892 +0300

Edit #3 (1 Oct, 11:04 UTC):
I've copied all the code (single file) to: http://pastebin.com/RJP6eQiy (Valid for 1 Month)

The relevant umount is in the cleanup procedure, line #346, that is umount "$DEST_DIR".

Improve this question
7
  • 1
    Does your script close any filehandles it opens in tmp? I am not sure but I think this might happen if your script leaves the fh open. Commented Sep 30, 2013 at 18:06
  • "With stat I noticed a change in the size of the folder, before an after the success in the unmount" Mount points are normal directories. If you mount something on a directory that has contents, the contents are inaccessible until you unmount whatever. Then they'll still be there, untouched. Commented Sep 30, 2013 at 18:11
  • 2
    @terdon Open files in the toplevel should show up with lsof +d, but the man page notes: "+d does NOT descend the directory tree, rooted at s. The +D D option may be used to request a full-descent directory tree search, rooted at directory D." Commented Sep 30, 2013 at 18:17
  • Can you run the lsof via sudo? This will show us for sure if something is using tmp that you're username isn't privy to. Commented Sep 30, 2013 at 18:24
  • @sim: I forgot to mention that all of the commands were run by root (including fuser and lsof) Commented Sep 30, 2013 at 20:52

1 Answer 1

Reset to default
2

I believe the disk needs a 'sync' first (to flush/write disk cache) before the umount. Add sync after your 'rm' command (some OS require two sync commands) and then umount. Your 'busy' message should go away.

Improve this answer
9
  • You were right, I used sync before the umount and it works properly! Thank you! Commented Sep 30, 2013 at 20:39
  • No, you never need to call sync before umount. Calling sync just happens to delay the unmounting enough; calling sleep would do the same. Commented Sep 30, 2013 at 21:46
  • @Gilles: How can I test this..? I executed time on the sync and got the output: real 0m0.261s user 0m0.000s sys 0m0.020s Commented Oct 1, 2013 at 10:01
  • 1
    @Dor You could test it by suspending all writes (noflushd does that, but I'm not sure if it would be suitable here, as it's fairly tied to the disk layer and to the way certain filesystems operate). If sleep works as a delay even when no syncing happens, this would demonstrate that sync is not needed. Alternatively, you can use logic: syncing is one of the first things that happens during the unmounting process. Commented Oct 1, 2013 at 10:08
  • @Gilles: Please see the answer of the user 'jeberle' here. What is your opinion? Commented Oct 1, 2013 at 13:12

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.