[ale] unmount problem

[Phil Turmel]

On 12/07/2013 12:16 PM, Damon L. Chesser wrote:
> On 12/07/2013 05:46 AM, Horkan Smith wrote:
>> Sean, you might try
>>
>> # fuser /path/media/drive
>>
>> as well, that should give you the PID of the process that's hanging
>> you up.
>>
>> Not sure if that uses the same info as the lsof cmd though....
>>
>> Damon, wouldn't a lazy umount like that run the risk of it *looking*
>> like it's unmounted, but not really *be* unmounted?
> 
> Not in my experience, but you could do a mount command and verify
> after.  And better still, sync wrote all files in the buffer to disk, so
> if you yank the drive, you get no data loss.  I suspect either the file
> manager is holding it open (are you in that dir?) or a term is holding
> it open (same, are you in that dir).  I thought about fuser, just cause 
> it was fun to say to customers and keep a straight face.  it would tell
> you the PID, then you can nuke it. But I took the tack that I would want
> it umounted, processes be damned and sync; umount -l would do that. 
> Plus, IIRC, umount -l will report a problem with unmounting it if it
> failed. The risk of lazy umount is data loss due to not writing buffers
> and processes reading blowing up.  It is a big hammer.

You should also know that the kernel can hold a mount if a kernel thread
has a file open.  fuser and lsof won't report that case.  The most
common reason is if an image file within the mount has been set up for
loopback.

FWIW,

Phil