I would guess that this is a result of some type of port-scanning, as all these messages indicate an incoming connection was terminated before the daemon got around to accept()ing it.
At least the nfsd and inetd messages can be interpreted in that way. I'm not entirely sure about the nfs4cbd callback daemon, but I suspect that is the same scenario. The only system that should be connecting to that would be the NFSv4 server - should it be necessary to revoke a delegation.
A packet capture might be helpful - look for TCP handshakes, followed by an immediate FIN or RST from the client side.
I suppose the other possibility is that the system is short of resources - particularly memory - although I'd expect other signs in that case, such as "cannot fork" messages - and a noticable performance degradation. The nfsd and inetd messages however do seem to indicate a connection is gone almost immediately after it is established.