http://bugzilla.novell.com/show_bug.cgi?id=584710
http://bugzilla.novell.com/show_bug.cgi?id=584710#c4
Neil Brown changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |NEEDINFO
InfoProvider| |Joachim.Reichelt@helmholtz-
| |hzi.de
--- Comment #4 from Neil Brown 2010-04-08 05:45:53 UTC ---
The tcpdump trace shows NLM (locking) requests being sent from client
to server. The server sends a TCP-level ACK, but there is no RPC reply.
This confirms that there is no firewall in the away and points at a
problem with lockd or possibly statd on the server.
err 107 is ENOTCONN. lockd has just accepted a new connection from a
client and went to check the address of the client end of the connection
and was told that the socket wasn't connected. The most likely cause is that
the client has already closed down the socket. Maybe it was impatient.
err 104 is ECONNRESET. This is similar to ENOTCONN. The server tried to
write on a socket and was told that the socket wasn't connected any longer.
However in the tcpdump trace there is no evidence of the client shutting
down a connection. So maybe the server is closing the connection for some
reason.
Do you see the message:
lockd: too many open connections, consider increasing the number of nfsd
threads
in the kernel logs at all. If so that would probably explain the problem.
There
is a patch in more recent kernels that increases the number of sockets that
lockd can use. It should be easy enough to backport.
If you don't see that message, then I am at a bit of a loss to explain the
problem.
We might need to turn on some rpc tracing on the server.
--
Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.