Como identificar um processo que não possui pid?

Question

Eu tenho um processo que escuta 2 portas: 45136 / tcp e 37208 / udp (na verdade eu assumo que é o mesmo processo). Mas o netstat não retorna nenhum pid:

netstat -antlp | grep 45136
tcp        0      0 0.0.0.0:45136           0.0.0.0:*           LISTEN      - 

O mesmo resultado com "grep 37208".

Eu também tentei o lsof:

lsof -i TCP:45136

Mas não retorna nada. É uma nova instalação do squeeze e eu realmente não sei o que poderia ser esse processo. Alguma idéia?

RESPOSTA Graças aos seus comentários, descobri o que era. Eu desinstalei o nfs-server nfs-common (depois de uma busca dkpg -get-selections | grep nfs) e o processo desconhecido desapareceu. Estranho que os processos do kernel não estejam marcados de forma alguma.

Obrigado novamente a vocês dois. ;)

    

Answer 1

netstat

Há um processo lá, o seu usuário não está a par de ver o que é. Esta é uma camada de proteção fornecida por lsof que impede você de ver isso. Simplesmente execute novamente o comando, mas prefixe-o usando o comando sudo .

$ sudo netstat -antlp | grep 45136

Até há um aviso sobre isso na saída de lsof na parte superior.

(Not all processes could be identified, non-owned process info will not be shown, you would have to be root to see it all.)

Exemplo

$ netstat -antlp | grep 0:111
tcp        0      0 0.0.0.0:111       0.0.0.0:*     LISTEN      -                   

$ sudo netstat -antlp | grep 0:111
tcp        0      0 0.0.0.0:111       0.0.0.0:*     LISTEN      1248/rpcbind

ss

Se você não está tendo sorte com netstat , talvez ss faça isso. Você ainda precisará usar sudo , e a saída pode ser um pouco mais enigmática.

Exemplo

$ ss -apn|grep :111
LISTEN     0      128         :::111             :::*     
LISTEN     0      128          *:111              *:*     

$ sudo ss -apn|grep :111
LISTEN     0      128         :::111             :::*      users:(("rpcbind",1248,11))
LISTEN     0      128          *:111              *:*      users:(("rpcbind",1248,8))

ID do processo ainda não está lá?

Há casos em que simplesmente não há um PID associado à porta TCP em uso. Você pode ler sobre o NFS, na resposta do @derobert , que é uma delas. Há outros. Tenho instâncias em que estou usando túneis ssh para me conectar a serviços como o IMAP. Estes estão aparecendo sem um ID de processo também.

Em qualquer caso, você pode usar uma forma mais detalhada de netstat , o que pode lançar luz adicional sobre qual processo está usando uma porta TCP.

$ netstat --program --numeric-hosts --numeric-ports --extend

Exemplo

$ netstat --program --numeric-hosts --numeric-ports --extend |grep -- '-' | head -10
Proto Recv-Q Send-Q Local Address               Foreign Address             State       User       Inode      PID/Program name   
tcp        0      0 192.168.1.103:936           192.168.1.3:60526           ESTABLISHED root       160024310  -                   
tcp        0      0 192.168.1.1:2049            192.168.1.3:841             ESTABLISHED sam        159941218  -                   
tcp        0      0 127.0.0.1:143               127.0.0.1:57443             ESTABLISHED dovecot    152567794  13093/imap-login    
tcp        0      0 192.168.1.103:739           192.168.1.3:2049            ESTABLISHED root       160023970  -                   
tcp        0      0 192.168.1.103:34013         192.168.1.3:111             TIME_WAIT   root       0          -                   
tcp        0      0 127.0.0.1:46110             127.0.0.1:783               TIME_WAIT   root       0          -                   
tcp        0      0 192.168.1.102:54891         107.14.166.17:110           TIME_WAIT   root       0          -                   
tcp        0      0 127.0.0.1:25                127.0.0.1:36565             TIME_WAIT   root       0          -                   
tcp        0      0 192.168.1.1:2049            192.168.1.6:798             ESTABLISHED tammy      152555007  -             

Se você perceber que a saída inclui o INODES, poderemos acompanhar o processo usando essas informações.

$ find -inum 152555007

Que mostrará um arquivo que pode levar você a um processo.

Referências

• Porta para PID

Answer 2

Outra opção é que o soquete não pertence a um processo, ele pertence ao kernel. Um exemplo comum disso é o NFS.

Watt:~# netstat -ltp | egrep -- '-[[:space:]]*$'
tcp        0      0 *:nfs                   *:*                     LISTEN      -               
tcp        0      0 *:48131                 *:*                     LISTEN      -               
tcp6       0      0 [::]:55607              [::]:*                  LISTEN      -               
tcp6       0      0 [::]:nfs                [::]:*                  LISTEN      -               

Eu não tenho certeza de um bom caminho, em geral, para identificá-los. No caso particular do NFS, rpcinfo geralmente será capaz de nos dizer:

anthony@Watt:~$ rpcinfo -p | grep 48131
    100021    1   tcp  48131  nlockmgr
    100021    3   tcp  48131  nlockmgr
    100021    4   tcp  48131  nlockmgr

Infelizmente, isso funciona apenas para o IPv4. Para obter o v6, você precisa deixar o -p , que exibe números de porta de maneira tola: Como dois octetos adicionais de endereço IP. Port 55607 torna-se assim 217.55 (porque 217 × 256 + 55 = 55607):

anthony@Watt:~$ rpcinfo  | grep -i 217.55
    100021    1    tcp6      ::.217.55              nlockmgr   superuser
    100021    3    tcp6      ::.217.55              nlockmgr   superuser
    100021    4    tcp6      ::.217.55              nlockmgr   superuser