O que o processo de pesquisa de rtsbpp está fazendo?

Question

No Ubuntu 12.04 LTS, quando executo o comando top , vejo um processo chamado rtsbpp-polling . Googling dá apenas alguns acessos ao fórum do Gentoo Linux que não parece ser relevante (eles não mencionam o processo).

$ 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]

Pesquisando rts_bpp indica que podem ser drivers para meu leitor de cartão, mas não tenho certeza se isso tem a ver com o processo rtsbpp-polling .

Então, o que isso faz?

Editar: Seguindo o conselho de Sim na resposta abaixo, parece que rts_bpp é de fato um driver:

$ 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 não aparece nessa lista e parece não fazer nada na rede, mas parece usar alguns arquivos. Não sei o que fazer com isso:

$ 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)

'

    

Answer 1

Leitor de Cartão PC?

Acredito que o segmento do Gentoo esteja correto. Acho que está relacionado a um leitor de placa de PC que você instalou no seu sistema. Eu encontrei este segmento que tem um módulo do kernel com o mesmo nome. O tópico é intitulado: leitor de cartão [RESOLVIDO] não funciona - RTL8411 - rts_bpp .

O processo lá, rts_bpp , especialmente me faz pensar que está relacionado. Você pode verificar se você tem o módulo do kernel correspondente instalado para confirmar um pouco mais.

$ sudo lsmod | grep rts

Você também pode ver qual hardware pode estar usando o módulo do kernel, se estiver presente:

$ sudo lspci -k | less

Em seguida, examine a saída de qualquer hardware que esteja usando os módulos do kernel. Por exemplo:

00:00.0 Host bridge: Intel Corporation Core Processor DRAM Controller (rev 02)
        Subsystem: Lenovo Device 2193
        Kernel driver in use: agpgart-intel

Observe o módulo do kernel que está sendo usado, agpgart-intel . Você provavelmente verá o hardware que está usando o módulo rts_bpp , se houver algum.

Depurando mais

O outro método de ataque seria examinar o processo em si. Você pode ver quais recursos de arquivo este processo misterioso está usando, bem como as portas TCP / UDP que ele pode ter em uso. Você pode usar essas duas ferramentas para fazer esse trabalho.

netstat

Você pode descobrir quais soquetes TCP / UCP ou Unix estão sendo usados por este processo da seguinte forma:

$ netstat -anp |grep udisk
unix  3      [ ]         STREAM     CONNECTED     16411  2198/udisks-daemon  
unix  3      [ ]         STREAM     CONNECTED     16404  2198/udisks-daemon  

O exemplo acima mostra a saída de amostra para o processo udisks-daemon . Está usando apenas soquetes.

Veja um exemplo de um processo usando os três:

$ 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

Para ver quais arquivos um processo está usando, você pode usar a ferramenta de linha de comando lsof . Por exemplo, aqui estão os mesmos 2 processos acima, udisks-daemon e rpc.statd . Observe também que estamos dizendo lsof os IDs de processo para esses dois processos usando a opção -p # .

Aqui está o udisks-daemon:

$ 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

Aqui está o 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)