NFS:continuous connection problem signalled in /var/log/messages

[Paolo Gilli]

Hi,
in /var/log/message there are continuous message like this:
Jun 15 08:04:19 localhost kernel: nfs: server lbdnas02 OK
Jun 15 08:04:20 localhost last message repeated 4 times
Jun 15 08:04:48 localhost kernel: nfs: server lbdnas02 not responding, still trying
Jun 15 08:04:50 localhost kernel: nfs: server lbdnas02 OK
Jun 15 08:04:51 localhost kernel: nfs: server lbdnas02 not responding, still trying
Jun 15 08:04:51 localhost kernel: nfs: server lbdnas02 OK
Jun 15 08:05:18 localhost kernel: nfs: server lbdnas02 not responding, still trying
Jun 15 08:05:21 localhost kernel: nfs: server lbdnas02 OK
Jun 15 08:05:49 localhost kernel: nfs: server lbdnas02 not responding, still trying
Jun 15 08:05:49 localhost last message repeated 2 times
Jun 15 08:05:50 localhost kernel: nfs: server lbdnas02 OK
Jun 15 08:05:51 localhost last message repeated 2 times
Jun 15 08:06:19 localhost kernel: nfs: server lbdnas02 not responding, still trying
Jun 15 08:06:21 localhost kernel: nfs: server lbdnas02 OK

I have change lan wire and port switch but the problem is not solved.

running linux on the server is:
Linux version 2.4.22 (root@athoa01) (gcc version 2.96 20000731 (Red Hat Linux 7.2 2.96-112.7.2)) #1 SMP Wed Nov 5 09:57:23 CET 2003

An other server linux rh2.1 and hp9000 ux11.0 works without problems via NFS on lbdnas02

any suggestions?
Thanks
Paolo

[Gopi Sekar]

this message generally printed when NFS service gets network timeout which means the connection between lbdnas02 and your linux box is not reliable. whether both machines are connected via LAN or WAN?

also other things to check is your route/DNS information on your target linux box. check whether it is trying with some non existing DNS or router. If so correct them and check.

Also try connecting NFS by TCP instead of default udp. check -o proto option in mount command of NFS

Regards,
Gopi

[Steven E. Protter]

Possible Causes:

1) The server lbdnas02 has gone offline.
2) A firewall has interfered with the connection.
3) Network infrastructure has interfered with the connection.
4) A problem with this server has caused the connection to go stale.
5) An nfs software flaw has caused this issue.
6) The lan card on this server has failed or is beginning to go bad.

You have covered cable an other simple causes.

I would suggest that you upgrade the Linux server at least for networking and NFS to make sure its not software patching. Then meticulous eliminate the other possible causes.

SEP

[Paolo Gilli]

Gopi, Steven,
Thankyou for your response.
I will start to investigate the point mentioned by Steven and then apply Gopi mount option.
Here other informations:

all connections between linux boxes and lbdnas02 are LAN connections.
The linux box(rh 7.2)with the connections problems and the linux box(rhAS 21)that works fine have the same NFS option.
mount command shows:
lbdnas02:/vol1r5/nfs on /nas type nfs (rw,noexec,nosuid,nodev,addr=192.168.248.5)
in /etc/fstab:lbdnas02:
lbdnas02:/vol1r5/nfs /nas nfs noauto,user 0 0

when mount NSF I use simply mount /nas on both linux box

linux box with problem work on:
2: eth0: mtu 1500 qdisc pfifo_fast qlen 100
link/ether 00:0b:cd:28:b4:f4 brd ff:ff:ff:ff:ff:ff
inet 192.168.249.66/22 brd 192.168.251.255 scope global eth0

linux box OK work on
2: eth0: mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:0b:cd:fe:1d:d8 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.170/24 brd 192.168.1.255 scope global eth0

[Steven E. Protter]

Another possibility.

There could be another box on the network trying to come up with the same IP addrss as the problem Linux box.

SEP

[Dave Falloon]

I had a similar problem once, due to a silly quirk of inetd. We ran the default nfs setup with minimal tweaks which meant that NFS connections were managed by inetd. Inetd has an dumb default number of allowed connections 50 in a minute. What it does is counts by the minute and once it hits its limit it denies connections until the minute is up and then it allows another 50 connections.

We had to change the line in inetd to increase the number of connections. This only applied to UDP connections because TCP connections were not handled through inetd.

I can't remember the specifics of what we changed it was something along these lines though:

rpc dgram udp wait root /usr/lib/netsvc/rwall/rpc.rwalld 100008 1 rpc.rwalld

rpc dgram udp wait.1000 root /usr/lib/netsvc/rwall/rpc.rwalld 100008 1 rpc.rwalld

man inetd.conf

This only applies if you are using inetd of course.

Also do *NOT* use soft mounts ( snipped from Linux NFS FAQ ):

E4. Why do I get NFS timeouts when I mount a Linux NFS server from my Solaris NFS client?

A. You get NFS timeouts because you are using soft mounts. Normally, mounts are hard, which requires the client to continue attempts to reach the server forever. A soft mount allows the client to stop trying an operation after a period of time. A soft timeout may cause silent data corruption if it occurs during data or metadata transmissions, so you should only use soft mounts in the cases where client responsiveness is more important than data integrity. If you require the use of soft mounts over an unreliable link such as DSL, try using TCP, which is what Solaris uses by default. This will help manage the impact of brief network interruptions. If using TCP is not possible, then you should reduce the risk of using soft mounts with UDP by specifying long retransmission timeout values and a relatively large number of retries in the mount command options (i.e., timeo=30, retrans=10).

Note that NFS over UDP now uses a retransmit timeout estimation algorithm in the latest 2.4 and 2.6 kernels, which means the timeo= mount option is less effective at preventing data corruption due to a soft timeout.

--Dave