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

10

У меня есть сервер Ubuntu / Hardy, с ядром 2.6.24-23-сервер и netstat:

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

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

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

ОБНОВИТЬ

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

linux networking ubuntu netstat
источник
2
Вы уверены, что запускаете его как root или с помощью sudo?
Дом
Да, он запускался от имени пользователя root и даже от имени пользователя root через sudo. тот же эффект.
Вы уверены, что не делали netstat -ntapвместо netstat ntap?
Кайл Брандт
Я уверен, что делал netstat -ntap- так же, как я написал. так как таким способом параметры задаются netstat в соответствии с его страницей руководства.
Примечание: я только что проверил, и кажется, что netstat не распознает параметры, заданные без "-".

Ответы:

4

Это происходит с процессами ядра, такими как 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)
mikemaccana
источник
3 
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) некоторые процессы запускаются в ядре

Ян Руан
источник
1

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

ombble
источник
Это определенно не соединения на основе ядра, так как это соединения с базой данных из приложения.
Вывод netstat -atnp | grep EST?
Уомбл
вот в чем моя проблема - соединения перечислены вместо имени pid / программы, которое у меня есть "-"
3
И я хотел бы увидеть, что на самом деле происходит, а не их интерпретацию.
Уомбл
Я не могу показать вам весь вывод, так как он содержит имена, которые можно использовать для идентификации среды. строка для этого конкретного порта выглядит следующим образом: "tcp 0 0 localhost: 36949 localhost: 6543 ESTABLISHED -"
1

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

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


источник
Паскаль: Вы запускали эту команду с помощью sudo или с правами root?
Стефан Ласевский
0

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

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

  1. все папки процессов в / proc итерированы, каждый fd в каталоге / proc // fd проверяется для построения карты от inode сокета до pid / progname.

  2. Затем проверяется / proc / net / tcp для получения информации о сокете tcp (с помощью функции tcp_info), включая inode сокета.

  3. при выводе информации о сокете tcp pid / progname запрашивается из карты на шаге 1 через inode сокета. если ничего не найдено, выводится '-'.

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

zenkj
источник