Por que o rpc.lockd está oculto na saída netstat / lsof?

Question

Prólogo:

Em várias máquinas, que agem como clientes NFS, netstat relata duas portas que estão abertas sem o PID listado para um daemon associado. Normalmente, isso pode ser um pouco preocupante.

# netstat -lnp | egrep -- '- +$'
tcp        0      0 0.0.0.0:57448           0.0.0.0:*               LISTEN     -
udp        0      0 0.0.0.0:48933           0.0.0.0:*                          -

Além disso, netcat confirma que a porta TCP está realmente aberta.

# nc -v localhost 57448
localhost [127.0.0.1] 57448 (?) open
^C

Ainda, lsof não informa nada para essas duas portas. A intriga cresce.

# lsof -i TCP:57448 -i UDP:48933

No entanto, rpcinfo finalmente nos aponta na direção certa. Está sendo mantido aberto por nlockmgr , também conhecido como lockd para NFS. Cancele a busca.

# rpcinfo -p | egrep '57448|48933'
    100021    1   udp  48933  nlockmgr
    100021    3   udp  48933  nlockmgr
    100021    4   udp  48933  nlockmgr
    100021    1   tcp  57448  nlockmgr
    100021    3   tcp  57448  nlockmgr
    100021    4   tcp  57448  nlockmgr

Torna-se claro que lockd / rpc.lockd é chamado ao montar uma exportação NFS. Este é um segmento do kernel (é sempre?) Que se liga a um TCP e uma porta UDP no intervalo efêmero. As portas geralmente são reconfiguráveis com os fs.nfs.nlm_tcpport e fs.nfs.nlm_udpport sysctls.

Perguntas:

Estou intrigado embora. Adoraria alguma introspecção interna do kernel quanto a ..

1. Por que o PID do segmento do kernel não está visível em netstat ?

2. Por que as portas limitadas não são visíveis de lsof ?

Answer 1

netstat e lsof crawl /proc/<pid>/fd para associar processos a ports / sockets e /proc/<pid>/fd não é preenchido para threads do kernel AFAIK.

O lockd é sempre um segmento do kernel - pelo menos em kernels modernos (mais recentes que o 2.2).