«Netstat -p» / «ss -p» не показывает процесс прослушивания порта

На моем CentOS 7 в какой-то момент sudo ss -plt порт, отмеченный как LISTENING, на *:30565 , но в колонке процесса его строки не было никакой информации. Другие прослушивающие порты показывали свой собственный процесс, как обычно, например, users:(("sshd",pid=1381,fd=3)) , но эта одна строка не имела никакой информации о процессе. lsof -i :30565 или netstat -p также не засовывали никакой информации.

Я не смог воспроизвести это, и я боюсь думать о ситуации, когда «не-процесс» может прослушивать порт (так как я уверен, что Linux делает запланированную очистку, когда умирает tcp-listen proess ). Как это бывает и с несколькими программами, единственное объяснение, о котором я могу думать, это то, что это «предназначенное, но очень руткит-y» поведение CentOS, но я, несомненно, что-то пропустил. Что могло бы вызвать это?

  • Память ussage для буферов сообщений TCP или именованных каналов?
  • Как читать строки с фиксированной скоростью?
  • Использование tcpdump для извлечения содержимого NFS RPC
  • Привязать непривилегированное приложение к привилегированному порту в Mac OS X
  • Соединение pfsense tcp между openvpn и lan нарушено
  • Простой TCP-сервер, прослушивающий порт, но не возвращающий SYN-ACK
  • IPv6 через TCP или TCP6
  • Что это диапазон min / max для SSH?
  • One Solution collect form web for “«Netstat -p» / «ss -p» не показывает процесс прослушивания порта”

    Точка netstat не отображающая информацию о процессе в некоторых ситуациях, например NFS, заключается в том, что NFS является модулем ядра и, как таковой, не работает как обычный процесс и не имеет PID.

    Вы можете регулярно размещать сообщения об этой ситуации, если включить NFS в свои поисковые запросы Google:

    netstat не сообщает имя PID / Program для некоторых портов

    Linux и Unix - лучшая ОС в мире.