[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Can't force unmount device



> On Monday, May 26, 2014 1:01 PM, The Wanderer <wanderer@fastmail.fm> wrote:

> > -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> On 05/26/2014 12:40 PM, Dr. Jennifer Nussbaum wrote:
> 
> 
>>  On Monday, May 26, 2014 12:32 PM, The Wanderer <wanderer@fastmail.fm>
>>  wrote:
> 
>>>  As far as the hangs themselves - first, I'd like to clarify
>>>  something.
>>> 
>>>  You say you mount the laptop by NFS to a local fileserver. I'm not
>>>  clear which direction you mean the mounting is done in.
>>> 
>>> 
>>>  That is:
>>> 
>>>  Machine A has a NFS share defined.
>>> 
>>>  Machine B runs an appropriate NFS mount command, and gains access
>>>  to files which are stored on machine A.
>>> 
>>>  Is the laptop machine A, or machine B?
>>> 
>>>  The former is what your phrasing ("I ... mount [the laptop] via 
> NFS
>>>  to a local fileserver") leads me to expect, but the latter would 
> be
>>>  the more common scenario.
>> 
>>  Yes, that's right. I have a fileserver at home that has an NFS share
>>  defined; this share is used by various machines on my home network,
>>  and by the laptop when i have the laptop at home.
> 
> So the laptop is machine B, then?

In your scheme, yes.
 
> That fits with the sort of scenario I would have expected. It's just
> that I read "mount [a machine] via NFS" as "mount a directory 
> that's
> being shared by [a machine] over NFS", so I found the phrasing confusing.

Sorry, my unclearness.
 
> By any chance, when the suspend failure and NFS hang occurs, is there an
> 'updatedb' or 'updatedb.mlocate' process running on the laptop?

No, i dont think so. This runs in the middle of the night and this is not
when i remove the laptop.

> updatedb normally runs once a day, by cron job, and scans all mounted
> filesystems for changes. It's supposed to ignore any filesystems of
> types listed in the PRUNEFS variable in /etc/updatedb.conf ; however,
> there appears to be a longstanding bug such that it does not in fact do
> this for (some?) NFS mounts. I can dig up one or more existing Debian
> bug reports for this if necessary.

Also updatedb never seems to index the NSF-mounted files.

And nfs/NFS are listed in this conf file.

>>  When im leaving home and the laptop doesnt need access to this, i
>>  (try to) unmount the share so i can suspend the laptop and leave.
> 
> If you always do unmount the share before taking the laptop off-network
> in this way, or if the problem sometimes occurs even when you did
> remember to unmount it, then I'm probably barking up the wrong tree.

I dont always unmount the share; sometimes i forget. But the problem occurs
even when i do try to unmount it, or rather i cant unmount the system as described
in my first message.

> However, if you ever suspend the laptop with the NFS share mounted, then
> wake it up again while not connected to the appropriate network to talk
> to the fileserver, that could produce the behavior you're seeing.

This does sometimes happen--i syspend the laptop, take it somewhere else, then
it cant find the fileserver when it wakes up. How can i solve this? (Apart
from just remembering to always unmount it before leaving home.)

> (The behavior could also occur if e.g. the laptop connects only
> wirelessly, and the wireless network connection drops during the time
> when updatedb wants to be scanning that filesystem. That's a less likely
> scenario, however.)

I connect the laptop both wired and wifi, but as said above it doesnt seem
to scan the filesystem using updatedb.


Reply to: