确认这lockd是一个内核模块

Question 1

阅读man nsfd其中部分内容：

   In the /proc filesystem there are 4 files that can be used to  enabled  extra  tracing  of
   nfsd and related code.  They are:
        /proc/sys/sunrpc/nfs_debug
        /proc/sys/sunrpc/nfsd_debug
        /proc/sys/sunrpc/nlm_debug
        /proc/sys/sunrpc/rpc_debug
   They  control tracing for the NFS client, the NFS server, the Network Lock Manager (lockd)
   and the underlying RPC layer respectively.  Decimal numbers can be read from or written to
   these  files.   Each number represents a bit-pattern where bits that are set cause certain
   classes of tracing to be enabled.  Consult the kernel header files to find out what number
   correspond to what tracing.

另请参阅https://docstore.mik.ua/orelly/networking_2ndEd/nfs/ch11_02.htm

Answer

阅读man nsfd其中部分内容：

   In the /proc filesystem there are 4 files that can be used to  enabled  extra  tracing  of
   nfsd and related code.  They are:
        /proc/sys/sunrpc/nfs_debug
        /proc/sys/sunrpc/nfsd_debug
        /proc/sys/sunrpc/nlm_debug
        /proc/sys/sunrpc/rpc_debug
   They  control tracing for the NFS client, the NFS server, the Network Lock Manager (lockd)
   and the underlying RPC layer respectively.  Decimal numbers can be read from or written to
   these  files.   Each number represents a bit-pattern where bits that are set cause certain
   classes of tracing to be enabled.  Consult the kernel header files to find out what number
   correspond to what tracing.

另请参阅https://docstore.mik.ua/orelly/networking_2ndEd/nfs/ch11_02.htm

Question 2

很抱歉回答三年前的问题，不过真的在网上很难找到关于这个主题的可靠信息，而且因为我自己费了很大劲才弄清楚低级细节，所以我想我也可以分享我的结果！

首先是一般的观察：当输出中的进程名称ps aux括在方括号中时，例如[lockd] 这通常意味着lockd我们正在处理内核线程。这解释了为什么中任何地方都没有（或类似名称的）可执行文件$PATH。

确认这`lockd`是一个内核模块

你可以使用该lsmod命令列出活动的内核模块，对我来说，这确实显示了一个lockd模块（我在本文中给出的所有示例均基于 Ubuntu 20.04 系统）：

$ lsmod | grep nfs
nfsd                  409600  11
auth_rpcgss            94208  1 nfsd
nfs_acl                16384  1 nfsd
lockd                 102400  1 nfsd
grace                  16384  2 nfsd,lockd
sunrpc                393216  30 nfsd,auth_rpcgss,lockd,nfs_acl

以下命令查找任何相关文件的位置：

$ locate lockd.ko
/usr/lib/modules/5.4.0-109-generic/kernel/fs/lockd/lockd.ko
/usr/lib/modules/5.4.0-110-generic/kernel/fs/lockd/lockd.ko

找到这些lockd.ko文件是一个明确的确认，它lockd是作为内核线程实现的。

谁负责启动`lockd`？

因为您提到想要重新启动，所以[lockd]我很好奇谁负责启动它，所以我进行了一些调查：

$ dpkg -L nfs-common | xargs -d '\n' grep -s lockd
Binary file /sbin/rpc.statd matches
Binary file /sbin/sm-notify matches

这些字符串引用的lockd实际内容如下：

$ strings /sbin/rpc.statd | grep lock
modprobe lockd

$ strings /sbin/sm-notify | grep lock
/proc/fs/lockd/nlm_end_grace

这回答了我在找到此页面时想要回答的问题：

守护lockd进程作为内核线程实现（并且似乎没有人负责监督它并在发生故障时重新启动）。
该statd守护进程似乎负责加载lockd.ko内核模块（根据strings上面的输出判断）。使用apt-get source nfs-common我可以确认utils/statd/statd.c包含条件system("modprobe lockd");调用。
守护statd进程由systemd启动并监督，可执行文件rpc.statd由单元调用并管理rpc-statd.service。

您提到已经尝试过，systemctl restart rpc-statd并且根据我的研究判断，一个人负责运行modprobe lockd，因此目前很难说手动modprobe lockd命令是否会对您的情况有所帮助，但是对于遇到此问题的任何人，我建议尝试一下。

Answer

很抱歉回答三年前的问题，不过真的在网上很难找到关于这个主题的可靠信息，而且因为我自己费了很大劲才弄清楚低级细节，所以我想我也可以分享我的结果！

首先是一般的观察：当输出中的进程名称ps aux括在方括号中时，例如[lockd] 这通常意味着lockd我们正在处理内核线程。这解释了为什么中任何地方都没有（或类似名称的）可执行文件$PATH。

确认这`lockd`是一个内核模块

你可以使用该lsmod命令列出活动的内核模块，对我来说，这确实显示了一个lockd模块（我在本文中给出的所有示例均基于 Ubuntu 20.04 系统）：

$ lsmod | grep nfs
nfsd                  409600  11
auth_rpcgss            94208  1 nfsd
nfs_acl                16384  1 nfsd
lockd                 102400  1 nfsd
grace                  16384  2 nfsd,lockd
sunrpc                393216  30 nfsd,auth_rpcgss,lockd,nfs_acl

以下命令查找任何相关文件的位置：

$ locate lockd.ko
/usr/lib/modules/5.4.0-109-generic/kernel/fs/lockd/lockd.ko
/usr/lib/modules/5.4.0-110-generic/kernel/fs/lockd/lockd.ko

找到这些lockd.ko文件是一个明确的确认，它lockd是作为内核线程实现的。

谁负责启动`lockd`？

因为您提到想要重新启动，所以[lockd]我很好奇谁负责启动它，所以我进行了一些调查：

$ dpkg -L nfs-common | xargs -d '\n' grep -s lockd
Binary file /sbin/rpc.statd matches
Binary file /sbin/sm-notify matches

这些字符串引用的lockd实际内容如下：

$ strings /sbin/rpc.statd | grep lock
modprobe lockd

$ strings /sbin/sm-notify | grep lock
/proc/fs/lockd/nlm_end_grace

这回答了我在找到此页面时想要回答的问题：

守护lockd进程作为内核线程实现（并且似乎没有人负责监督它并在发生故障时重新启动）。
该statd守护进程似乎负责加载lockd.ko内核模块（根据strings上面的输出判断）。使用apt-get source nfs-common我可以确认utils/statd/statd.c包含条件system("modprobe lockd");调用。
守护statd进程由systemd启动并监督，可执行文件rpc.statd由单元调用并管理rpc-statd.service。

您提到已经尝试过，systemctl restart rpc-statd并且根据我的研究判断，一个人负责运行modprobe lockd，因此目前很难说手动modprobe lockd命令是否会对您的情况有所帮助，但是对于遇到此问题的任何人，我建议尝试一下。

确认这lockd是一个内核模块

答案1

答案2

确认这`lockd`是一个内核模块

谁负责启动`lockd`？

相关内容

答案1

答案2

确认这lockd是一个内核模块

谁负责启动lockd？

相关内容

确认这`lockd`是一个内核模块

谁负责启动`lockd`？