Почему rpc.lockd скрыт от вывода netstat/lsof?

Пролог:

На нескольких машинах, которые действуют как клиенты NFS, netstat сообщает о двух портах, которые открыты без PID в списке для ассоциированного демона. Обычно это может быть немного связано.

# 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:*                          -

Дополнительно netcat подтверждает, что порт TCP действительно открыт.

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

Еще lsof ничего не сообщает для этих двух портов. Интрига растет.

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

тем не мение rpcinfo наконец указывает нам в правильном направлении. Это держится открытым nlockmgrака lockd для NFS. Отмени поиск.

# 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

Становится ясно, что lockd/rpc.lockd вызывается при монтировании экспорта NFS. Это поток ядра (всегда ли это?), Который связывает себя с одним портом TCP и одним портом UDP в эфемерном диапазоне. Порты обычно реконфигурируемы с fs.nfs.nlm_tcpport а также fs.nfs.nlm_udpport параметров ядра.

Вопросы:

Я заинтригован, хотя. Хотелось бы немного внутреннего понимания ядра, чтобы...

  1. Почему PID потока ядра не виден из netstat?

  2. Почему связанные порты не видны из lsof?

1 ответ

Решение

netstat и lsof оба ползают /proc/<pid>/fd связать процессы с портами / сокетами и /proc/<pid>/fd не заполняется для потоков ядра AFAIK.

lockd - это всегда поток ядра - по крайней мере, на современных (более новых, чем, скажем, 2.2) ядрах.

Другие вопросы по тегам