Почему 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
параметров ядра.
Вопросы:
Я заинтригован, хотя. Хотелось бы немного внутреннего понимания ядра, чтобы...
Почему PID потока ядра не виден из
netstat
?Почему связанные порты не видны из
lsof
?
1 ответ
netstat и lsof оба ползают /proc/<pid>/fd
связать процессы с портами / сокетами и /proc/<pid>/fd
не заполняется для потоков ядра AFAIK.
lockd - это всегда поток ядра - по крайней мере, на современных (более новых, чем, скажем, 2.2) ядрах.