netstat -ntap nie wyświetla nazwy pid / procesu dla niektórych połączeń?

11

Mam serwer ubuntu / hardy, z jądrem 2.6.24-23-server i netstat:

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

Problem polega na tym, że mamy wiele USTAWIONYCH połączeń, które nie pokazują PID ani nazwy programu na netstat -ntapwyjściu. Netstat został wywołany z roota, nie ma chrootów, grsecurity, ani niczego takiego (przynajmniej tak mi powiedziano :).

Masz pojęcie, co może być nie tak?

AKTUALIZACJA

lsof -n -i działa dobrze i wyświetla nazwę pid / process dla połączeń.

2

Czy na pewno uruchomisz go jako root lub z sudo?

— Dom,

Tak, był uruchamiany na rootie, a nawet na rootowaniu przez sudo. ten sam efekt.

Czy na pewno nie robiłeś netstat -ntaptego zamiast netstat ntap?

— Kyle Brandt,

Jestem pewien, że robiłem netstat -ntap- tak jak napisałem. ponieważ w ten sposób podane są opcje dla netstat zgodnie ze stroną man.

Uwaga dodatkowa - właśnie sprawdziłem i wydaje się, że netstat nie rozpoznaje opcji podanych bez „-”.

4

Dzieje się tak w przypadku procesów jądra, takich jak NFS, ale czasami występuje również w przypadku zwykłych aplikacji: RHEL 5 ma takie samo zachowanie.

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

Zauważ, że lsof z kolei poprawnie słowa:

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

— mikemaccana
źródło

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:~ #

w mojej głowie mogą być dwie sytuacje:

1) normalny użytkownik z uprawnieniami do wyceny „netstat” nie widzi procesów uruchomionych przez roota

2) niektóre procesy działają w jądrze

— Yans Ruan
źródło

1

W przypadku ustanowionych połączeń powinno to nastąpić tylko w przypadku połączeń inicjowanych z przestrzeni jądra, takich jak NFS lub DRBD. Oczywiście czekające połączenia mogły umrzeć pod nimi. Jeśli nie możesz ustalić, co powoduje dane połączenie, wklej dane wyjściowe, a ktoś powie ci, co to jest.

— womble
źródło

Z pewnością nie są to połączenia oparte na jądrze, ponieważ są to połączenia z bazą danych z aplikacji.

Wyjście netstat -atnp | grep EST?

— womble

to jest mój problem - połączenia są wymienione przez zamiast pid / nazwa programu mam "-"

3

I chciałbym zobaczyć, co się właściwie dzieje, a nie jego interpretację.

— womble

Nie mogę wyświetlić całego wyniku, ponieważ zawiera nazwy, które można wykorzystać do identyfikacji środowiska. linia dla tego konkretnego portu wygląda następująco: „tcp 0 0 localhost: 36949 localhost: 6543 ESTABLISHED -”

1

Mam takie samo zachowanie i domyślam się, że zachowanie netstat mogło się zmienić. Na przykład widzę port i program dla „wget”, ale nie dla procesów Apache PHP, które są dla mnie ważniejsze.

Obejście: Przepisałem skrypt, aby zamiast niego użyć lsof (patrz wskazówka powyżej)

Pascal: Czy uruchomiłeś to polecenie z sudo czy jako root?

— Stefan Lasiewski

0

Przyjedź tutaj, ponieważ w dzisiejszych czasach spotykam to samo pytanie na Ubuntu 18.04 LTS (netstat to ta sama wersja netstat 1.42 (2001-04-15)), dziwne wciąż brak odpowiedzi po 8 latach. Po przejrzeniu kodu źródłowego net-tools mogę go znaleźć.

W kodzie źródłowym netstat:

wszystkie foldery procesu w / proc są iterowane, każdy fd w katalogu / proc // fd jest sprawdzany, aby zbudować mapę z i-węzła gniazda do pid / progname.
następnie sprawdzane jest / proc / net / tcp, aby uzyskać informacje o gnieździe tcp (przez funkcję tcp_info), w tym i-węzeł gniazda.
podczas wyprowadzania informacji o gnieździe tcp, pid / prognoza jest odpytywany z mapy w kroku 1 przez i-węzeł gniazda. jeśli nic nie zostanie znalezione, wypisuje „-”.

Jeśli gniazdo zostanie utworzone po zbudowaniu mapy, pid / prognozy nie zostaną znalezione na mapie.

— zenkj
źródło