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