Вопрос или проблема
У меня сервер ubuntu/hardy с ядром 2.6.24-23-server и netstat:
# netstat --version
net-tools 1.60
netstat 1.42 (2001-04-15)
Проблема в том, что у нас много ESTABLISHED соединений, которые не показывают 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)
Для установленных соединений это должно происходить только для соединений, инициированных из пространства ядра, таких как NFS или DRBD. Очевидно, что ожидающие соединения могли быть закрыты процессом, который завершился в это время. Если вы не можете выяснить, что вызывает данное соединение, вставьте вывод, и кто-то сможет подсказать, что это.
Добрался сюда, потому что в последнее время сталкиваюсь с тем же вопросом на ubuntu 18.04 LTS (netstat той же версии netstat 1.42 (2001-04-15)), странно, что нет ответа спустя 8 лет. После изучения исходного кода net-tools я, возможно, нашел ответ.
В исходном коде netstat:
-
все папки процессов в /proc перебираются, каждый fd в директории /proc//fd проверяется для создания карты от inode сокета к pid/имени программы.
-
затем проверяется /proc/net/tcp для получения информации о tcp сокете (функция tcp_info), включая inode сокета.
-
при выводе информации о tcp сокете pid/имя программы запрашивается из карты на шаге 1 по inode сокета. если ничего не найдено, выводится ‘-‘.
Если сокет был создан после построения карты, pid/имя программы не будут найдены в карте.
У меня такое же поведение, и я предполагаю, что поведение netstat могло измениться. Например, я вижу порт и программу для ‘wget’, но не вижу для процессов Apache PHP, которые более важны для меня.
Решение: я переписал свой скрипт, чтобы использовать lsof вместо этого (см. подсказку выше).
Ответ или решение
При выполнении команды netstat -ntap на вашем сервере Ubuntu могут возникать ситуации, когда PID и имя процесса не отображаются для некоторых соединений. Эта проблема может быть вызвана несколькими факторами, и ниже мы рассмотрим наиболее вероятные причины и способы их решения.
Возможные причины:
-
Процессы запущены не от имени root:
Еслиnetstatзапускается не от имени пользователя root, то вы можете не увидеть PID или имя процесса для тех соединений, которые принадлежат другим пользователям. Однако, вы упомянули, что команда выполнялась от имени root, что исключает эту ситуацию. -
Процессы, работающие на уровне ядра:
Некоторые соединения могут быть инициированы процессами, работающими непосредственно в пространстве ядра, такими как NFS. В этом случаеnetstatможет не отобразить их в своем выводе, в то время какlsofработает корректно. -
Обновление данных в
/proc:
Если сокет был создан после того, какnetstatсобрал данные из/proc, PID и имя процесса не будут найдены. Это связано с тем, чтоnetstatстроит карту процессов, просматривая каталоги процессов в/proc, и если сокет был создан после этого прохождения, он не будет отображен с PID и именем программы. -
Версия утилит и их поведение:
Учитывая, что ваша версияnetstatустарела (1.42 от апреля 2001 года), существует вероятность, что в ней могут быть ошибки или недостатки, которые исправлены в более современных версиях инструментов сетевого мониторинга.
Рекомендации по решению проблемы:
-
Использование lsof:
Как вы уже заметили,lsof -n -iпоказывает PID и имя процесса для операций с сетевыми соединениями более надежно, чемnetstat. Вы можете использовать его в своих скриптах и командах для получения более точной информации о сетевых соединениях. -
Обновление утилит:
Рассмотрите возможность обновления своей системы на более новую версию Ubuntu или хотя бы установки современных утилит сетевого мониторинга, таких какss, которые могут предоставить более оптимизированный и точный вывод. -
Проверка процессов на предмет зависших или завершенных:
Иногда соединения могут оставаться активными после завершения процесса, который их создал. Проверьте, нет ли зависших процессов, которые могли бы привести к такой ситуации. -
Мониторинг в реальном времени:
Если вы хотите следить за созданием новых соединений в реальном времени, вы можете использовать команды, такие какtcpdump, для анализа сетевого трафика или инструменты мониторинга, которые предоставляют более детализированные отчеты.
Заключение:
Ваше беспокойство о том, почему netstat не отображает PID и имя процесса для некоторых соединений, вполне обосновано. Наиболее надежный способ решения — использовать lsof для проверки соединений. Обновление инструментария и использование современных альтернатив, таких как ss, может значительно улучшить вашу способность отслеживать сетевые соединения и процессы.