Re: Can't force unmount device
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 05/26/2014 01:15 PM, Dr. Jennifer Nussbaum wrote:
> On Monday, May 26, 2014 1:01 PM, The Wanderer <wanderer@fastmail.fm>
> wrote:
>
>> On 05/26/2014 12:40 PM, Dr. Jennifer Nussbaum wrote:
>>> 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.
>> 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.
I wouldn't have expected it to be a problem either, for that exact
reason, but I've seen this issue repeatedly on my own laptop when I
don't unmount an NFS share before leaving my home network to go to work.
The updatedb cron job is supposed to run at 6:25 AM (I think), but in
some cases I've seen it running at considerably later times. I haven't
tracked down the reason, or if I have I've forgotten it.
>> 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.
It's not supposed to, and of course if it can't access the filesystem it
won't be able to.
> And nfs/NFS are listed in this conf file.
Yes - as I said, there's a bug such that they get ignored even though
they're listed there.
>>> 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.
I apologize, I was unclear. By the time you attempt a suspend that will
fail, I would expect the updatedb process to already be hung, from a
*previous* (probably successful) suspend attempt where the unmount did
not get run.
The scenario I'm envisioning is:
* You mount the NFS share.
* You suspend successfully, without unmounting the share.
* You leave the network where the fileserver is.
* You wake up the laptop.
* updatedb starts trying to scan the NFS share.
* You attempt to suspend, or to unmount the share, and fail.
I've seen that exact scenario repeatedly in my own use. However, now
that I look at it more closely, it doesn't seem like an exact match for
what you've described; for one thing, it would mean you'd be seeing the
failure when suspending while away from home, rather than when
suspending to leave home.
>> 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.)
Depends what you mean by "solve".
To let the suspend succeed when the process is already hung, you should
be able to just kill the 'updatedb.mlocate' process. You'll have to run
the kill command as root, and you may well need the exact PID rather
than being able to use 'pkill' or 'killall' to kill it by name.
To prevent the updatedb hang from happening, you have to prevent
updatedb from trying to scan the detached NFS mount.
One way to do that is to always unmount the filesystem before
suspending, but as you've noted, there's no guarantee you'll always
remember to do that.
Another way would be to remove the updatedb cron job entirely, so that
it doesn't run at all. That seems like drastic overkill if you ever
actually use the locate command, but it would get the job done.
Another way would be to get the PRUNEFS bug fixed. That would be the
best option; if you choose to pursue it, good luck.
- --
The Wanderer
Secrecy is the beginning of tyranny.
A government exists to serve its citizens, not to control them.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBCgAGBQJTg3uOAAoJEASpNY00KDJrI+MQAKelICbM5fAZcx0vkEGBfU5Z
XCSGHO80MtwqbBDxuPfvoGFV6l+sexBBethSskoSt7hORVDMBrX7CNSmuUFQWsqY
hIoSJ72IFLzRGTGftMjlPZ8ga1WFS/2+yK927uvnvltZCOQhOy1L4JLsF9anSwu5
2ph5UvqR+8p0cwKw1Vg9HULWzVwGuv9qg0rJZ8cLeIknwhkZHHcWgMq3lLRXxtyy
Os99FioQ8fQsNqal0Xrk7U5o/L1NP7b76W31IXYnP9NPX1B9uXsGrp6IXgsnAY3Q
CKYgY8GQV1PugHz64/k/p6oGxiwOdp5rjIdYwTdUS93U3NUiHWD1Ns9GMIL5K0Wz
bnv8jOu+MdkNit5lfvYq5MqQ9lBwm8hapcDN51/unc5aWO/jzDfMnPOFCybzPA7J
EZUboCr8Kx9XEJ86kba62m5/mALy/XpJgFh2F5T+YHT2eClpjS53fwqDuGTzfH1z
CKoHQdpDijcbU6TmIaTUMEpanWq3TK4Ywh+Ik2un7G5cuCNys/beNncrLmRxzvt1
P+pZvgS2aYKHjRNYU5/L/TgSVYNWlBU6A41cDDaMTT5xi6gSo3NyD87/0DTQc6No
VZnn4dAbUyku5Kq8+Es8y3V5ezzMN5Sp5Me09uBnJlO6NFaeVMNdQ6+dunW3GuYI
v1bFFvfiohYL4U8skA2z
=aACf
-----END PGP SIGNATURE-----
Reply to: