> On Monday, May 26, 2014 1:01 PM, The Wanderer <wande...@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 <wande...@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.
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/1401124540.89418.yahoomail...@web124506.mail.ne1.yahoo.com
