☰

为什么 rpc.lockd 在 netstat/lsof 输出中被掩盖了？

tag-icon • tag-icon linux nfs netstat rpc lsof
为什么 rpc.lockd 在 netstat/lsof 输出中被掩盖了？

序幕：

在许多充当 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 端口。这些端口通常可以使用和 sysctls 重新fs.nfs.nlm_tcpport配置fs.nfs.nlm_udpport。

问题：

不过我很感兴趣。很想了解一些内核内部的见解……

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

  2. 为什么不可见绑定的端口lsof？

答案1

据我所知，netstat 和 lsof 都爬行/proc/<pid>/fd以将进程关联到端口/套接字，并且/proc/<pid>/fd不会填充内核线程。

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

相关内容