-----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 <wande...@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----- -- 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/53837b8e.3020...@fastmail.fm