Como identificar um processo que não tem pid?

Eu tenho um processo que escuta duas portas: 45136 / tcp e 37208 / udp (na verdade, eu suponho que seja 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      - 

Mesmo resultado com "grep 37208".

Eu também tentei lsof:

lsof -i TCP:45136

Mas isso não retorna nada. É uma nova instalação do squeeze e eu realmente não sei o que poderia ser esse processo. Qualquer ideia ?

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

Obrigado novamente a ambos. ;)

netstat

Há um processo lá, seu userid simplesmente não está a par de ver o que é. Essa é uma camada de proteção fornecida lsof, impedindo que você veja isso. Simplesmente execute novamente o comando, mas prefixe-o usando o sudocomando.

$ sudo netstat -antlp | grep 45136

Há até um aviso sobre isso na saída do lsoftopo.

(Nem todos os processos puderam ser identificados; as informações de processo não pertencentes a ele não serão mostradas; você precisaria ser root para ver tudo.)

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, netstattalvez ssfaça. 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 casos em que estou usando túneis ssh para conectar-me novamente a serviços como IMAP. Eles também estão aparecendo sem um ID do processo.

De qualquer forma, você pode usar uma forma mais detalhada netstatque possa 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ê notar que a saída inclui INODES, podemos voltar ao processo usando essas informações.

$ find -inum 152555007

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

Referências

• Porta para PID

Outra opção é que o soquete não pertence a um processo, 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 uma boa maneira, em geral, para identificá-los. No caso particular do NFS, rpcinfomuitas vezes 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 IPv4. Para obter a v6, é necessário interromper -p, que exibe os números de porta de maneira boba: Como dois octetos adicionais de endereço IP. A porta 55607 passa a ser 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