NFS mounts after sleep problem.

intermittent problem with an NFS mount that doesn't always work after waking a sleeping G4.
Simon Tennant wrote on :

I have been experiencing an intermittent problem with an NFS mount that doesn't always work after waking a sleeping G4. Most of the time the mount works after a sleep but sometimes the system log shows the following and never manages to remount. A reboot fixes the problem:

Jul 10 08:38:00 g4/g4 configd[37]: posting notification com.apple.system.config.network_change Jul 10 08:38:00 g4/g4 lookupd[358]: lookupd (version 369.5) starting - Mon Jul 10 08:38:00 2006 Jul 10 08:38:00 g4/g4 configd[37]: hostname (reverse DNS query) = g4.imagilan Jul 10 08:38:00 g4/g4 configd[37]: setting hostname to "g4.imagilan" Jul 10 08:38:00 g4/g4 configd[37]: setting hostname to "g4.imagilan" Jul 10 08:38:01 g4/g4 kernel[0]: short receive (1456/10284) from nfs server 10.7.11.1:/home Jul 10 08:38:01 g4/g4 kernel[0]: short receive (1456/10284) from nfs server 10.7.11.1:/home Jul 10 08:38:01 g4/g4 kernel[0]: short receive (1456/10284) from nfs server 10.7.11.1:/home Jul 10 08:38:01 g4/g4 kernel[0]: nfs server 10.7.11.1:/home: can not connect, error 13 Jul 10 08:38:01 g4/g4 kernel[0]: nfs server 10.7.11.1:/home: can not connect, error 13 Jul 10 08:38:01 g4/g4 kernel[0]: nfs server 10.7.11.1:/home: can not connect, error 13 Jul 10 08:38:01 g4/g4 automount[156]: handle_deferred_requests: processing pending VFS Event... Jul 10 08:38:01 g4/g4 KernelEventAgent[32]: tid 00000000 received VQ_NOTRESP event (1) Jul 10 08:38:01 g4/g4 KernelEventAgent[32]: tid 00000000 received VQ_NOTRESP event (1) Jul 10 08:38:01 g4/g4 KernelEventAgent[32]: tid 00000000 type 'nfs', mounted on '/private/var/automount/home', from '10.7.11.1:/home', not responding Jul 10 08:38:01 g4/g4 KernelEventAgent[32]: tid 00000000 type 'nfs', mounted on '/private/var/automount/home', from '10.7.11.1:/home', not responding Jul 10 08:38:01 g4/g4 KernelEventAgent[32]: tid 00000000 found 1 filesystem(s) with problem(s) Jul 10 08:38:01 g4/g4 KernelEventAgent[32]: tid 00000000 found 1 filesystem(s) with problem(s) Jul 10 08:38:01 g4/g4 kernel[0]: nfs server 10.7.11.1:/home: can not connect, error 13 Jul 10 08:38:01 g4/g4 kernel[0]: nfs server 10.7.11.1:/home: can not connect, error 13 Jul 10 08:38:01 g4/g4 kernel[0]: nfs server 10.7.11.1:/home: can not connect, error 13 Jul 10 08:38:02 g4/g4 kernel[0]: nfs server 10.7.11.1:/home: not responding

mount shows:

10.7.11.1:/home on /private/var/automount/home

and the mount is mounted with the following options:

-P (allow all ports, not just privileged) -3 (NFS v3) -r=32768 -w=32768 (read and write size) -T (NFS over TCP)

Unfortunately the Linux server that holds the mount shows no errors and I would be surprised if there were a problem at that end since rebooting the Mac fixes the problem.

I am also curious as to whether the mac supports non-automounted/static mounts? Automount seems more effort than it is worth especially for mounts that should never expire.

Any clues greatfully received.

S.

Jonathan Schneider replied on :

Does normal UDP NFS work ?

Linux isn't too hot in the NFS department. I didn't know it even supported TCP NFS so wouldn't surprise me if it was flaky.

Although I'd expect NFS to create a new connection maybe the existing TCP connection is in a funny undead state.

Jon

Simon Tennant replied on :

Jonathan Schneider wrote:

Does normal UDP NFS work ?

Am trying that for the next couple of days to see if it is something to do with a stale TCP connection.

Linux isn't too hot in the NFS department. I didn't know it even supported TCP NFS so wouldn't surprise me if it was flaky.

Linux NFS has come on a lot over the last 2 years. Granted the 2.4 kernel days NFS were nothing fantastic, however the 2.6 kernel's NFSv3 support over TCP and UDP are very stable. The NFSv4 support is also progressing nicely. But, there is no excuse for randomly restarting demons without fully understand the correct start order and how the different components of RPC & NFS work together.

Although I'd expect NFS to create a new connection maybe the existing TCP connection is in a funny undead state.

Hopefully that is the problem.

Jon