为什么 rpc.lockd 从 netstat/lsof 输出中被遮挡？

Question

序幕：

在许多恰好充当 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，这两个端口没有报告任何内容。阴谋增长。

# lsof -i TCP:57448 -i UDP:48933

然而，rpcinfo最终为我们指明了正确的方向。它由nlockmgr，又名lockdNFS保持开放。取消搜索。

# 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_udpportsysctls重新配置。

问题：

不过我很好奇。会喜欢一些内核内部的洞察力...

1. 为什么内核线程的 PID 不可见netstat？

2. 为什么从 中看不到绑定的端口lsof？

Answer 1

netstat 和 lsof 都爬行/proc/<pid>/fd以将进程与端口/套接字相关联，并且/proc/<pid>/fd不会为内核线程 AFAIK 填充。

lockd 始终是一个内核线程 - 至少在现代（比 2.2 版本更新）内核上是这样。