序幕：
在多台机器上，这些机器恰好充当NFS客户端， netstat报告两个打开的端口，没有为关联的守护进程列出PID。 通常这可能有点关心。
# netstat -lnp | egrep -- '- +$' tcp 0 0 0.0.0.0:57448 0.0.0.0:* LISTEN - udp 0 0 0.0.0.0:48933 0.0.0.0:* -
另外， netcat确认TCP端口确实是打开的。
# nc -v localhost 57448 localhost [127.0.0.1] 57448 (?) open ^C
但是这两个港口没有任何报道。 阴谋增长。
# lsof -i TCP:57448 -i UDP:48933
然而rpcinfo最后指出我们在正确的方向。 它被nlockmgr打开，也被nlockmgr为NFS。 closuressearch。
# rpcinfo -p | egrep '57448|48933' 100021 1 udp 48933 nlockmgr 100021 3 udp 48933 nlockmgr 100021 4 udp 48933 nlockmgr 100021 1 tcp 57448 nlockmgr 100021 3 tcp 57448 nlockmgr 100021 4 tcp 57448 nlockmgr
很明显，挂载NFS导出时会调用lockd / rpc.lockd 。 这是一个内核线程（它总是？），它将自己绑定到临时范围内的一个TCP和一个UDP端口。 端口通常可以使用fs.nfs.nlm_tcpport和fs.nfs.nlm_udpport sysctl进行重新configuration。
问题：
虽然我很好奇。 会喜欢一些核心内部的洞察力
为什么从netstat不能看到内核线程的PID？
为什么不能从lsof看到绑定的端口？
netstat和lsof都将crawl /proc/<pid>/fd关联进程到端口/套接字，而/proc/<pid>/fd不会被内核线程AFAIK填充。
lockd总是一个内核线程 – 至less在现代（比2.2更新）的内核上。