[vorläufig erledigt]NFS-Share bleibt sporadisch hängen

[stollenreiter]

Ich habe hier ein Problem, das ich nicht in den Griff bekomme.
Auf einem server1 habe ich eine Freigabe, die auf anderen Servern gemountet wird. Das ist ja auch eigentlich kein Problem. Die Server stehen zwar bundesweit verteilt und sind über ein MPLS verbunden, aber auch das dürfte ja nicht das Problem sein. Insgesamt funktioniert das ja auch wochen-/monatelang ohne Probleme.
Doch dann rennt der server2, auf dem die Freigabe gemountet ist, Amok.

top - 16:15:49 up 36 days, 4:36, 3 users, load average: 17.97, 17.45, 17.07
Tasks: 308 total, 1 running, 307 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.2%us, 0.0%sy, 0.0%ni, 99.8%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 4146764k total, 4005108k used, 141656k free, 238496k buffers
Swap: 2104504k total, 60788k used, 2043716k free, 2694392k cached

Wobei halt die Auslastung eigentlich nocht hoch ist. Zum Teil bekomme ich auch Zombie-Prozesse.

Selbst ein

umount -l /mnt/share

bringt nichts. Ich habe dann auch schon auf den Servern die Dienste nfs-common und nfs-kernel-server neu gestartet. Auch kein Erfolg.

Ein

mount -vvv /mnt/share

bringt dann folgendes

mount: fstab path: "/etc/fstab"
mount: lock path: "/etc/mtab~"
mount: temp path: "/etc/mtab.tmp"
mount: spec: "server1:/home/share"
mount: node: "/mnt/share"
mount: types: "nfs"
mount: opts: "rw,users,noauto,timeo=1,nfsvers=3"
mount: external mount: argv[0] = "/sbin/mount.nfs"
mount: external mount: argv[1] = "server1:/home/share"
mount: external mount: argv[2] = "/mnt/share"
mount: external mount: argv[3] = "-v"
mount: external mount: argv[4] = "-o"
mount: external mount: argv[5] = "rw,noexec,nosuid,nodev,noauto,users,timeo=1,nfsvers=3"
mount.nfs: trying server1 prog 100003 vers 3 prot TCP port 2049
mount.nfs: trying server1 prog 100005 vers 3 prot UDP port 59609

Die Angabe timeo und nfsvers habe ich mal testweise mit reingenommen. Kommt aber das gleiche bei raus.

Auf dem server1 steht in der syslog dann das

server1 mountd[10435]: authenticated mount request from server2:1000 for /home/share (/home/share)

Der mount auf server2 bleibt stehen und in der syslog taucht das hier auf

[3114147.120233] nfs: server1 not responding, timed out
[3114147.120295] nfs: RPC call returned error 88
[3114147.120396] nfs: RPC call returned error 88

Hier die exports auf server1

"/home/share" *(rw,no_root_squash,sync,no_subtree_check)

server1 hat die nfs-version

nfs-common 1:1.2.2-4squeeze2
nfs-kernel-server 1:1.2.2-4squeeze2

server2 (der die Freigabe mountet)

nfs-common 1:1.1.2-6.28.201007201157
nfs-kernel-server 1:1.1.2-6.28.201007201157

[rendegast]

Kernelwechsel <-> andere nfs-/nfsd-Module.

Falls testing/jessie, vielleicht das rpcbind aus stable/wheezy versuchen?
(Andersherum geht nicht wegen Abhängigkeit Version libc6)

Insgesamt funktioniert das ja auch wochen-/monatelang ohne Probleme.

walkaround durch einen gelegentlichen/regelmäßigen reexport/remount?


Falls nur der Client server2 betroffen ist,
vielleicht hat der andere Probleme, zBsp. in Richtung Netzwerkkarte/Netzwerkkartentreiber?

[stollenreiter]

Hallo rendegast.

Vielen Dank für die schnelle Antwort.

Leider kann ich den Kernel beim Client-Server nicht ändern, da es sich in dem Fall um gekaufte Software handelt und ich dann den Support durch die Firma verlieren würde. Die Firma sagt mir natürlich auch, dass das Problem durch meine Server ausgelöst wird. Obwohl beides debian/squeeze ist.

Bei den Servern, die die Freigaben haben, könnte ich den Kernel austauschen. Momentan läuft dort noch debian/squeeze. Vielleicht reicht auch schon ein Upgrade auf stable.

Ich hatte nur die Hoffnung, dass ich vielleicht den Fehler genauer einkreisen kann und gegebenenfalls den "schwarzen Peter" der Software-Firma zuschieben kann.

Gruß stollenreiter

[rendegast]

Momentan läuft dort noch debian/squeeze. Vielleicht reicht auch schon ein Upgrade auf stable.

Da gäbe es zwei einfache Möglichkeiten
"kernel": squeeze 2.6.32 <-> squeeze-backports 3.2
"RPC": squeeze rpcbind <-> squeeze portmap

Obwohl beides debian/squeeze ist.

Auch auf aktuellem Stand bei dem eingekauften Client-Server?
ZBsp. Kernel 2.6.32-48squeeze4, 2013-09.
(solche Fertigserver werden häufig im Auslieferungszustand belassen)

[stollenreiter]

Auf den gekauften Servern arbeitet ein

2.6.32-ucs37-686-bigmem

Kernel. Auf den eigenen Servern ein

2.6.32-5-686 #1 SMP Fri May 10

Dann werde ich mal deinen Vorschlag mit den Backports auf den eigenen Servern umsetzen.