up vote 2 down vote favorite
share [g+] share [fb]

A detachable device like eSATA, USB drive can be abruptly removed (by simply pulling the plug).

If there are open file handles on a partition, then this partitions won't unmount, i.e. the Linux umount command will fail, even AFTER the drive is physically detached.

If the unmount fails, then on reattachment of the device, the mount will fail as well. So you have to find out which processes are using the drive and kill them or close all the handles. If you cannot do either, you will have to reboot the box to get your drive mounted. And I can definitely not kill the process using it.

I see no "force unmount" option, there is a -f option, but it is only for NFS.

This sounds very strange,doesn't Linux accommodate for this scenario where a user simply yanks a drive? Does anyone know how to handle this scenario gracefully in Linux?

Is there any way to find out what file handles are open on a particular partition/device or selectively flush and close all file handles only for a particular device?

Note: The lsof command is not available in the embedded Linux that I am using (busybox).

"fuser" is not available in my embedded linux.

I tried the lazy umount -l. However, it does not seem to consistently work. Say for e.g. I keep a file handle open (with "tail -f" on some file on the device). Then I detach a drive and then I do "umount -l" and it unmounts. And then I reattach the drive and try to mount it again on the same mount point, while the tail is still running. It does not consistently work. Sometimes it succeeds and sometimes it does not. This makes me uncomfortable using the lazy option what if it leaves the file system in inconsistent state. And also am not sure if this lazy option was meant to be used for such scenarios.

I cannot kill the process which has file handles open.

It seems if I have mounted the device on say /mnt/abc and if I disconnect the drive and then reconnect, Linux seems to re-attach the device's file system to the same mount point "/mnt/abc", without us doing any unmount or mount. And then the same old open file handles seems to start working after reattachment (atleast for file read operation). This is my observation. I am not sure if this is the expected behavior.. However, this also does not seem to be working consistently.

I had an open file handle for reading ("tail -f") which I left open, then I detached and reattached and then modified the file being tailed and I saw the "tail -f" output getting updated with the changes. However, if I try to modify a file after the device was gone( it gives error as expected) and then I reattach, the device's file system does not get properly re-attached to the same mount point. In case of a file write (while the device was not there) it does not seem to be working.

Is there any standard/consistent behavior that Linux follows when a drive is removed abruptly without closing all handles and properly unmounting all partitions ?

link|improve this question
feedback

migrated from stackoverflow.com Sep 7 '11 at 11:14

This question came from our site for professional and enthusiast programmers.

4 Answers

up vote 1 down vote

You can use lsof to list open files under a certain directory using lsof +D /path/to/mountpoint.

link|improve this answer
Thanks for the response. Actually lsof is not available in the embedded linux that I am using. lsof is not available in busybox. – solidstate Sep 7 '11 at 10:01
feedback
up vote 0 down vote

Have you tried: 

umount -l /path/to/mountpoint
Or

fuser -km /path/to/mountpoint
?

Ok, so my previous suggestions didn't work out. I know it might be stupid, but have you actually tried: 

umount -f /path/to/mountpoint

According to the Busybox documentation it should be the force unmount option (showing NFS as an example).

If that doesn't work, have you tried: 

eject -s /dev/my-sata-or-usb-device

link|improve this answer
According to the OP, fuser is not available, and umount -l does not work consistently (see edits to question) – slhck Sep 7 '11 at 16:10
Weren't there when I posted, huh. Well, that kills my ideas. :( – Justin Pearce Sep 7 '11 at 16:15
thanks. eject is not available. umount -f does not work (even after the drive is physically disconnected and there's an open file handle - "tail -f") it says umount: cannot forcibly umount /mnt/abc: Device or resource busy – solidstate Sep 13 '11 at 10:04
I'm out of ideas, sorry. :( – Justin Pearce Sep 13 '11 at 14:48
feedback
up vote 0 down vote

You can write a bash script to scan all the file descriptors listed in /proc (assume you have that) and list/kill the processes.

/proc/$m/fd/$n is the n-th file descriptor for PID m presented as a symbolic link. busybox does have readlink support, so you should be able to automatic it.

Edit: Just to say this is essentially re-implementing lsof, but it's actually fairly simple.

link|improve this answer
Thanks for the response. But from the fd present in /proc/$m/fd can I find out which device or volume it belongs to. I need that, I need to close the fds of the detachable device(eSATA) ONLY on disconnection and not the others which may be a socket fd or file handle on internal device. – solidstate Sep 13 '11 at 10:11
Is there any reliable way to find out which fd/file handle (from the /proc) belongs to which device and volume ? – solidstate Sep 13 '11 at 11:54
Sorry about replying so late. A basic/(not so reliable) way to do this is to use readlink to get the path the fds are point to and compare them with the mount point listed by mount. E.g. something like if readlink $fd | grep ^$mount-point ; then .... fi – billc.cn Sep 16 '11 at 13:33
Thanks billc.cn. But why do you say it is "not so reliable", whats wrong with this approach. When could it give wrong results? – solidstate Sep 25 '11 at 4:10
The problem is with comparing the path with the mount points. If a program opened a file via a symbolic link, this would not work. – billc.cn Sep 25 '11 at 21:09
show 1 more comment
feedback
up vote 0 down vote

2 ideas:

The I cannot kill the process which has file handles open. means that you can't kill it like terminate it or that you can't use any kill signal on it, because you don't have access to the kill command ?

If you have kill access you could try sending a SIGIO to the process that had the file opened

You could also try to mount the removed drive and them use the mount ..... -o move: command to move the mountpoint of the drive.

link|improve this answer
I do have the kill command in busybox. But how will sending SIGIO help here ? AFAIK, SIGIO is for getting signals when new data is available in the file.Is it something else ? – solidstate Sep 13 '11 at 15:17
You'll have to try, don't know what programs are left with the open file handler while someone disconnected the drive. Each program can / might deal with a different outcome for each signal it receives, so it's worth taking a chance. – woliveirajr Sep 13 '11 at 15:39
feedback

Your Answer

 
or
required, but never shown
discard

Not the answer you're looking for? Browse other questions tagged or ask your own question.