NFS lockd Fehler

[lziegler]

Hallo alle zusammen,

ich hab einen Server auf OpenSuSE 10.3 upgedatet und hatte heute folgendes Problem:
Von jetzt auf gleich haben alle angemeldeten Clients (alle ebenfalls 10.3) keine Reaktion mehr gezeigt. Ein Blick in log-Files des Servers und der Clients brachte folgende Meldung zum vorschein:


lockd: couldn't create rpc handle

Als ich dann auf dem Server den Befehl


rpcinfo -u localhost 100021

eingegeben hab, hab ich die Meldung erhalten: RPC Timeout.

Die Konsequenz war, ich musste den Server komplett neu booten, damit wieder was gegangen ist. Ein einfacher Neustart der Dienste (NFS .....) hat nichts gebracht. Ich befürchte, dass dieser Fehler wieder auftritt, und hoffe auf einen Rat, was man dagegen machen kann.

Hab bereits alle Updates und neusten OpenSuSE Kernel installiert.

[lziegler]

Heute ist mir das selbe schon wieder passiert. Hat denn keiner eine Idee für dieses Problem?
Der Server dient als NFS-Server, LDAP-Anmelde-Server, Samba-Server, Squid-Proxy und es läuft antivir.

Ausstattung: 2 Dual-Core Opteron, 4GB RAM, SCSI Raid5, 7 Gigabit Netzwerkkarten, wobei 2 zu einem Bonding-Device zusammengefasst sind.

Ich hab auch manchmal den Eindruck, dass die SuSE-Firewall Probleme mit dem Bonding-Device hat, da beim Starten der Firewall immer wieder mal zu lesen ist, dass dem Device keine Zone zugewiesen sei, und daher der externen Zone zugewiesen wird, obwohl das Device der internen Zone zugewiesen ist.

[cane]

Das gelesen?

http://www.google.de/search?q=lockd%3A+couldn't+create+rpc+handle&ie=utf-8&oe=utf-8&aq=t&rls=com.ubuntu:de:official&client=firefox-a


Dann poste mal die Ausgaben wie die von "rpcstatus" nach denen allgemein gefragt wird.

mfg
cane

[lziegler]

Ja da hab ich schon gestöbert, aber keine Lösung gefunden.

Ich nehme an du meintest rpcinfo -p localhost. rpcstatus gibts bei mir nicht.


program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100005 1 udp 32772 mountd
100005 1 tcp 50324 mountd
100005 2 udp 32772 mountd
100005 2 tcp 50324 mountd
100005 3 udp 32772 mountd
100005 3 tcp 50324 mountd
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 4 udp 2049 nfs
100021 1 udp 32773 nlockmgr
100021 3 udp 32773 nlockmgr
100021 4 udp 32773 nlockmgr
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100003 4 tcp 2049 nfs
100021 1 tcp 48177 nlockmgr
100021 3 tcp 48177 nlockmgr
100021 4 tcp 48177 nlockmgr
100011 1 udp 637 rquotad
100011 2 udp 637 rquotad
100011 1 tcp 638 rquotad
100011 2 tcp 638 rquotad
100024 1 udp 2687 status
100024 1 tcp 14771 status

[lziegler]

Schade dass mir hier keiner helfen kann. Bis jetzt hab ich noch keine Lösung gefunden, und das Problem scheint immer häufiger aufzutreten.

Wenn sich zu viele Clients anmelden, erscheint irgendwann die oben genannte Fehlermeldung, und kein Linux-Client im Netzwerk reagiert mehr.

Wenn man den nfsserver gestoppt hat, muss man die Module nfsd und lockd entladen und erneut laden, um nach dem Neustart des nfsservers wieder Zugriff auf die nfs-Freigaben zu bekommen.

Die Windows-Rechner, die über samba und openldap angebunden sind haben keine Probleme.

Was soll ich noch machen???

[lziegler]

ach ja ich hab auch schon den neusten Kernel der OpenSuSE Factory Version installiert. Hat auch nichts gebracht.

[BedriddenTech]

Guck dir mal die Dateiliste deiner NFS-Utils an, u.a. gehts um /var/lib/nfs (oder wo auch immer SuSE das hat). Da liegen diverse Client-/Serverinformationen (sm, sm.bak, xtab, usw). Zeig mir mal bitte die Rechte dieser Dateien. :)

[lziegler]

Hier mal die Rechte.


-rw-r--r-- 1 root root 142 Jan 9 21:33 etab
-rw-r--r-- 1 root root 2125 Jan 23 17:06 rmtab
drwxr-xr-x 2 root root 4096 Sep 21 23:50 rpc_pipefs
drwx------ 2 root root 4096 Jan 23 17:06 sm
drwx------ 2 root root 4096 Jan 23 17:04 sm.bak
-rw-r--r-- 1 root root 4 Jan 23 17:02 state
drwxr-xr-x 2 root root 4096 Sep 21 23:50 v4recovery
-rw-r--r-- 1 root root 0 Sep 21 23:50 xtab


Was mich nur wundert, dass der Fehler immer dann auftritt, wenn scheinbar zu viele locks angelegt werden.

[BedriddenTech]

Eigentlich sollten da einige nobody gehören. Re-installier mal hart das NFS-Paket. Bei mir schauts nämlich so aus:

$ ls -la /var/lib/nfs
insgesamt 6
drwxrwxr-x 4 nobody root 1024 23. Jan 15:20 .
drwxr-xr-x 22 root root 2048 24. Dez 22:18 ..
-rwxrwxr-x 1 nobody root 0 1. Dez 04:45 etab
-rwxrwxr-x 1 nobody root 0 1. Dez 04:45 rmtab
drwxrwxr-x 2 nobody root 1024 23. Jan 15:20 sm
drwxrwxr-x 2 nobody root 1024 23. Jan 15:20 sm.bak
-rw-r--r-- 1 root root 4 23. Jan 15:20 state
-rwxrwxr-x 1 nobody root 0 1. Dez 04:45 xtab

Und ich weiß, daß Rechteprobleme hier Probleme beim Locking verursachen können.

[lziegler]

Aber nfs wird doch vom root-user gesteuert?!? Damit ist er doch der einzige der da schreiben muss. Oder nicht.
Wenn nicht, könnte ich doch einfach die Rechte der Verzeichnisse ändern?

[lziegler]

Ich hab auch noch einen 10.2 Server laufen. Bei dem sind genau die gleichen Rechte und der hat keine Probleme.

[BedriddenTech]

Der statd läuft bei mir unter dem Benutzer "nobody".

[lziegler]

Also ich hab mal geschaut. selbst wenn ich die Rechte ändere, werden die automatisch wieder umgestellt, sobald eine neue lock-Datei angelegt wird.
Ich hab so den Verdacht, dass da irgendwas im Kernel faul ist.

[Scumpeter]

Hi, ich habe hier das gleiche Problem.

Wir mounten unsere /home-Verzeichnisse über NFS. Wenn der Fehler auftritt, lassen sich einige Programme nicht mehr starten (kde, firefox, ...) einige andere gehen (fluxbox, xterm, ...). Ich vermute, die Programme, die sich nicht starten lassen, müssen etwas auf /home schreiben.

Wenn ich die Besitzer in /var/lib/nfs anpasse, dann läuft wieder alles.
Aber auch bei mir ändert sich der Besitzer einiger Dateien nach einiger Zeit wieder von nobody:root zu root:root.

Am Kernel liegt es wahrscheinlich nicht. Der ist schon eine Weile älter, als das Problem.

Der Server ist ein Gentoo-Rechner mit 2.6.23er Kernel und nfs-utils-1.1.0.

Gruß,
Peter.