在 Ubuntu 12.04 LTS 中，当我运行top命令时，我看到一个名为 的进程rtsbpp-polling。谷歌搜索只给出了 Gentoo Linux 论坛的一些点击，这似乎并不相关（他们没有提到这个过程）。
$ ps ax | grep rtsbpp
541 root 20 0 0 0 0 S 0 0.0 0:37.08 [rtsbpp-polling]
$ ps aux | grep rts
root 536 0.0 0.0 0 0 ? S 17:41 0:00 [rts_bpp]
root 541 0.6 0.0 0 0 ? S 17:41 0:38 [rtsbpp-polling]
谷歌搜索rts_bpp表明它可能是我的读卡器的驱动程序，但我不确定它与该rtsbpp-polling过程有什么关系。
那么它有什么作用呢？
编辑：按照 Sim 在下面的答案中的建议，它似乎rts_bpp确实是一个驱动程序：
$ sudo lspci -k | less
04:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. Device 5289 (rev 01)
Subsystem: ASUSTeK Computer Inc. Device 1447
Kernel driver in use: rts_bpp
Kernel modules: rts_bpp`
rtsbpp-polling没有出现在该列表中，并且似乎没有在网络上执行任何操作，但它似乎确实使用了一些文件。我不知道该怎么做：
$ lsof -p 726
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
rtsbpp-po 726 root cwd unknown /proc/726/cwd (readlink: Permission denied)
rtsbpp-po 726 root rtd unknown /proc/726/root (readlink: Permission denied)
rtsbpp-po 726 root txt unknown /proc/726/exe (readlink: Permission denied)
rtsbpp-po 726 root NOFD /proc/726/fd (opendir: Permission denied)
`
答案1
电脑读卡器？
我相信 Gentoo 线程是正确的。我认为这与您的系统上可能安装的 PC 卡读卡器有关。我发现这个线程有一个类似命名的内核模块。该线程的标题是：[已解决] 读卡器无法工作 - RTL8411 - rts_bpp。
那里的过程，rts_bpp尤其让我认为它是相关的。您可以检查是否安装了相应的内核模块以进一步确认。
$ sudo lsmod | grep rts
您还可以查看哪些硬件可能正在使用内核模块（如果存在）：
$ sudo lspci -k | less
然后查看使用内核模块的任何硬件的输出。举些例子：
00:00.0 Host bridge: Intel Corporation Core Processor DRAM Controller (rev 02)
Subsystem: Lenovo Device 2193
Kernel driver in use: agpgart-intel
请注意正在使用的内核模块agpgart-intel。您可能会看到哪些硬件正在使用该rts_bpp模块（如果有的话）。
进一步调试
另一种攻击方法是仔细检查进程本身。您可以查看这个神秘进程正在使用哪些文件资源以及它可能正在使用的 TCP/UDP 端口。您可以使用这两个工具来完成这项工作。
网络统计
您可以了解此进程正在使用哪些 TCP/UCP 或 Unix 套接字，如下所示：
$ netstat -anp |grep udisk
unix 3 [ ] STREAM CONNECTED 16411 2198/udisks-daemon
unix 3 [ ] STREAM CONNECTED 16404 2198/udisks-daemon
上面显示了该过程的示例输出udisks-daemon。它只使用套接字。
以下是使用这三个过程的示例：
$ netstat -anp |grep rpc.statd
tcp 0 0 0.0.0.0:54927 0.0.0.0:* LISTEN 1431/rpc.statd
tcp 0 0 :::46051 :::* LISTEN 1431/rpc.statd
udp 0 0 0.0.0.0:45563 0.0.0.0:* 1431/rpc.statd
udp 0 0 0.0.0.0:759 0.0.0.0:* 1431/rpc.statd
udp 0 0 :::36515 :::* 1431/rpc.statd
unix 2 [ ] DGRAM 10790 1431/rpc.statd
拉索夫
要查看进程正在使用哪些文件，您可以使用命令行工具lsof。例如，这里是与上面相同的 2 个进程udisks-daemon和rpc.statd。另请注意，我们使用开关告知lsof这 2 个进程的进程 ID -p #。
这是 udisks 守护进程：
$ sudo lsof -p 2198 | tail
lsof: WARNING: can't stat() fuse.gvfs-fuse-daemon file system /home/saml/.gvfs
Output information may be incomplete.
udisks-da 2198 root 8u unix 0xffff880228108680 0t0 16411 socket
udisks-da 2198 root 9r FIFO 0,8 0t0 16413 pipe
udisks-da 2198 root 10w FIFO 0,8 0t0 16413 pipe
udisks-da 2198 root 11r REG 0,3 0 4026531965 /proc/mdstat
udisks-da 2198 root 12u sock 0,6 0t0 16423 can't identify protocol
udisks-da 2198 root 13r FIFO 0,8 0t0 1768055 pipe
udisks-da 2198 root 14w FIFO 0,8 0t0 1768055 pipe
udisks-da 2198 root 15r REG 0,3 0 16424 /proc/2198/mountinfo
udisks-da 2198 root 16r FIFO 0,8 0t0 16450 pipe
udisks-da 2198 root 17w FIFO 0,8 0t0 16450 pipe
这是 rpc.statd：
$ sudo lsof -p 1431 | tail
lsof: WARNING: can't stat() fuse.gvfs-fuse-daemon file system /home/saml/.gvfs
Output information may be incomplete.
rpc.statd 1431 rpcuser 0u CHR 1,3 0t0 4066 /dev/null
rpc.statd 1431 rpcuser 1u CHR 1,3 0t0 4066 /dev/null
rpc.statd 1431 rpcuser 2u CHR 1,3 0t0 4066 /dev/null
rpc.statd 1431 rpcuser 4u unix 0xffff88022e976d80 0t0 10790 socket
rpc.statd 1431 rpcuser 5u IPv4 10902 0t0 UDP *:con
rpc.statd 1431 rpcuser 6w REG 253,0 5 1966234 /var/run/rpc.statd.pid
rpc.statd 1431 rpcuser 8u IPv4 10907 0t0 UDP *:45563
rpc.statd 1431 rpcuser 9u IPv4 10911 0t0 TCP *:54927 (LISTEN)
rpc.statd 1431 rpcuser 10u IPv6 10915 0t0 UDP *:36515
rpc.statd 1431 rpcuser 11u IPv6 10919 0t0 TCP *:46051 (LISTEN)