Mailinglist Archive: opensuse-bugs (4724 mails)

< Previous Next >
[Bug 584710] lockd: cannot monitor
  • From: bugzilla_noreply@xxxxxxxxxx
  • Date: Thu, 8 Apr 2010 05:45:54 +0000
  • Message-id: <20100408054554.6E8DB245520@xxxxxxxxxxxxxxxxxxxxxx>

Neil Brown <nfbrown@xxxxxxxxxx> changed:

What |Removed |Added
InfoProvider| |Joachim.Reichelt@helmholtz-
| |

--- Comment #4 from Neil Brown <nfbrown@xxxxxxxxxx> 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

Do you see the message:

lockd: too many open connections, consider increasing the number of nfsd

in the kernel logs at all. If so that would probably explain the problem.
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
We might need to turn on some rpc tracing on the server.

Configure bugmail:
------- You are receiving this mail because: -------
You are on the CC list for the bug.

< Previous Next >