netstat -ntap не показывает имя pid / процесса для некоторых подключений?

У меня есть сервер ubuntu / hardy с ядром 2.6.24-23-server и netstat:

# netstat --version
net-tools 1.60
netstat 1.42 (2001-04-15)

Проблема в том, что у нас много УСТАНОВЛЕННЫХ соединений, которые не показывают PID или имя программы в netstat -ntap вывод. Netstat был вызван из root, здесь нет chroots, grsecurity или чего-то подобного (по крайней мере, мне так сказали :).

Есть идеи, что может быть не так?

ОБНОВИТЬ

lsof -n -i работает нормально и показывает имя pid / процесса для соединений.

198_141:~ # netstat  -anp|grep 33000
tcp        0      0 0.0.0.0:53000           0.0.0.0:*               LISTEN       -                   
198_141:~ # lsof -i:33000
COMMAND   PID USER   FD   TYPE     DEVICE SIZE NODE NAME
vsftpd  28147 root    3u  IPv4 4089990174       TCP *:33000 (LISTEN)
198_141:~ # id
uid=0(root) gid=100(users) groups=16(dialout),100(users)
198_141:~ #

на мой взгляд, может быть две ситуации:

1) обычный привилегированный пользователь выполняет "netstat" не может видеть процессы, запущенные root

2) некоторые процессы выполняются в ядре

Это будет происходить с процессами ядра, такими как NFS, но также иногда происходит с обычными приложениями: RHEL 5 имеет такое же поведение.

# netstat -taupen | grep 30715
tcp        0      0 0.0.0.0:30715           0.0.0.0:*               LISTEN      66558      81467710   -

Обратите внимание, что lsof, с другой стороны, правильно определяет слова:

# lsof -i:30715
AppName 1598 useracct   78u     IPv4           81467710                   TCP *:30715 (LISTEN)

У меня такое же поведение, и я предполагаю, что поведение netstat могло измениться. Например, я вижу порт и программу для wget, но не для процессов Apache PHP, которые для меня важнее.

Обходной путь: я переписал свой скрипт, чтобы вместо этого использовать lsof (см. Подсказку выше)

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

Приезжайте сюда, потому что в эти дни я сталкиваюсь с тем же вопросом о ubuntu 18.04 LTS (netstat - это та же версия netstat 1.42 (2001-04-15)), странно, что все еще нет ответа через 8 лет. После просмотра исходного кода сетевых инструментов я могу его найти.

В исходном коде netstat:

все папки процессов в / proc повторяются, каждый fd в каталоге / proc // fd проверяется, чтобы построить карту от inode сокета до pid / progname.
затем / proc / net / tcp проверяется на получение информации о сокете tcp (функцией tcp_info), включая индексный дескриптор сокета.
при выводе информации о сокете tcp, pid / progname запрашивается из карты на шаге 1 через индексный дескриптор сокета. если ничего не найдено, выводится '-'.

Если сокет создается после построения карты, идентификатор pid / progname не будет найден на карте.