nfsv4 on Jaunty client causes nfs servers to spew time out errors

Bug #373979 reported by buntunub
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
nfs-utils (Ubuntu)
New
Undecided
Unassigned

Bug Description

Binary package hint: nfs-kernel-server

Since installing Kubuntu Jaunty (fresh install, remapped /home) I now have been getting constant client time out errors on my 32 bit Hardy nfs server. This ONLY happens with the Jaunty client (I have other clients and get no errors with them). Logs below but here is a sample dump:

May 9 01:57:24 dave234 kernel: [177807.957370] nfs4_cb: server 192.168.11.3 not responding, timed out
May 9 01:58:24 dave234 kernel: [177867.954953] nfs4_cb: server 192.168.11.3 not responding, timed out
May 9 01:59:24 dave234 kernel: [177927.944540] nfs4_cb: server 192.168.11.3 not responding, timed out
May 9 02:00:24 dave234 kernel: [177987.942121] nfs4_cb: server 192.168.11.3 not responding, timed out

This was also linked to another bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/253004 in which that same server would lock up due to these constant errors caused by the Jaunty client. The fix for this was patched and I am now running that patched kernel. No server lockups have occured since, but the primary error still continues and is that needs fixing.

Revision history for this message
buntunub (mckisick) wrote :

Here are the server log dumps

Revision history for this message
buntunub (mckisick) wrote :

Here is the client log dumps

Revision history for this message
buntunub (mckisick) wrote :

Oh. I just noticed this --

nepomukservices[4039]: segfault at 8 ip 00007fcbbf332cfe sp 00007fffc7935b50 error 4 in libQtCore.so.4.5.0[7fcbbf2c9000+240000]

And that does happen every boot, but I guess thats yet another bug to follow up on with Jaunty..

Anyway, I have googled up on this nfs issue quite a lot and from what I have noticed, upstream seems to not really take too much stock in this issue as it seems to be some type of harmless call back issue that is harmless as far as the protocol goes. Above my head though so I am really clueless as to this, but considering this issue never cropped up with Fedora10 when I had that loaded on this same client, nor with Hardy, same machine, one would have to assume that whatever was done with the Jaunty kernel is causing this problem. I also disabled the firewall, and modified the fstab with "clientaddr=192.168.11.3", thinking THAT might be causing a problem, but no joy!

Revision history for this message
buntunub (mckisick) wrote :

Here is the thread that speaks to this exact issue.

http://news.gmane.org/gmane.linux.nfsv4

In short, the guys say that its a harmless string, but as you can see from my server logs, this is troublesome because of the overabundance of the strings and how large my /var is filling up. The thread also speaks to a patch that was put into the 2.6.27 kernel to turn off printing. If thats the case, then can this patch be backported to the Hardy kernel so the LTS release can get this fix as well?

Revision history for this message
buntunub (mckisick) wrote :

Here is a wireshark snippet showing the nfs ack/reply. It does show that the client is responding but the server fails to see it for some reason. Firewalls are off on both at that time.

Revision history for this message
Jeremy Vies (jeremy.vies) wrote :

Hi
I confirm the problem with a Jaunty 9.04 client and Hardy 8.04.2 server.
My server locks up at least twice a day...

I'm glad it is not a hardware problem !!

Revision history for this message
buntunub (mckisick) wrote :

Has there been any work or progress made on this bug? Any intention to get this fixed?

Revision history for this message
buntunub (mckisick) wrote :

Update to this. I installed Archlinux GNOME and the issue went bye bye. This, along with a few other tests I ran leads me to strongly suspect Knetworkmanager as being the culprit. I believe a workaround might be using WICD or GNOME network manager, but never really had a chance to fully test that.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.