netstat -ntap не показує ім'я pid / процес для деяких з'єднань?


11

У мене є сервер ubuntu / hardy, з ядром 2.6.24-23-сервером і netstat:

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

Проблема полягає в тому, що у нас багато встановлених з'єднань, які не показують PID, ані ім'я програми у netstat -ntapвиході. Netstat викликався з root, немає жодних хротонів, грубобезпеки, нічого подібного (або мені так сказали :).

Будь-яка ідея про те, що може бути неправильним?

ОНОВЛЕННЯ

lsof -n -i працює нормально та показує назву pid / process для з'єднань.


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)

4
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. Очевидно, що з'єднання, що чекають, могли мати процес загибелі під ними. Якщо ви не можете розробити те, що викликає певне з'єднання, вставте висновок і хтось може сказати вам, що це таке.


Це, безумовно, не з'єднання на основі ядра, оскільки це підключення до бази даних від програми.

Вихід netstat -atnp | grep EST?
живіт

це моя проблема - підключення перераховані замість імені pid / програми, у мене є "-"

3
І я хотів би побачити, що насправді відбувається, а не їх інтерпретацію.
живіт

Я не можу показати вам весь результат, оскільки він містить імена, які можуть бути використані для ідентифікації середовища. рядок для цього конкретного порту виглядає приблизно так: "tcp 0 0 localhost: 36949 localhost: 6543 ВСТАНОВЛЕНО -"

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 socket до pid / progname.

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

  3. при виведенні інформації про сокет tcp, pid / progname запитується з карти на етапі 1 через вхід сокета. якщо нічого не знайдено, '-' виводить.

Якщо сокет буде створений після побудови карти, pid / progname не знайдеться на карті.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.