Jak rozpoznać proces, który nie ma pid?

Mam proces, który nasłuchuje 2 portów: 45136 / tcp i 37208 / udp (w rzeczywistości zakładam, że jest to ten sam proces). Ale netstat nie zwraca żadnego pid:

netstat -antlp | grep 45136
tcp        0      0 0.0.0.0:45136           0.0.0.0:*           LISTEN      - 

Ten sam wynik z „grep 37208”.

Próbowałem też lsof:

lsof -i TCP:45136

Ale nic nie zwraca. To nowa instalacja squeeze i naprawdę nie wiem, co to może być ten proces. Dowolny pomysł ?

ODPOWIEDŹ Dzięki twoim komentarzom dowiedziałem się, co to było. Odinstalowałem nfs-server nfs-common (po dkpg --get-selections | grep nfs search) i nieznany proces zniknął. Dziwne jest jednak to, że procesy jądra nie są w żaden sposób oznaczone.

Jeszcze raz dziękuję wam obojgu. ;)

netstat

Tam jest proces, twój identyfikator użytkownika po prostu nie ma uprawnień do zobaczenia, co to jest. Jest to warstwa ochrony, która zapewnia, lsofże nie możesz tego zobaczyć. Po prostu ponownie uruchom polecenie, ale sudozamiast tego użyj prefiksu .

$ sudo netstat -antlp | grep 45136

Na lsofgórze znajduje się nawet ostrzeżenie .

(Nie można zidentyfikować wszystkich procesów, informacje o procesach nieposiadających własności nie zostaną wyświetlone, musisz być rootem, aby zobaczyć wszystko.)

Przykład

$ netstat -antlp | grep 0:111
tcp        0      0 0.0.0.0:111       0.0.0.0:*     LISTEN      -                   

$ sudo netstat -antlp | grep 0:111
tcp        0      0 0.0.0.0:111       0.0.0.0:*     LISTEN      1248/rpcbind

ss

Jeśli nie masz szczęścia, netstatmoże ci się ssuda. Nadal będziesz musiał użyć sudo, a dane wyjściowe mogą być nieco bardziej tajemnicze.

Przykład

$ ss -apn|grep :111
LISTEN     0      128         :::111             :::*     
LISTEN     0      128          *:111              *:*     

$ sudo ss -apn|grep :111
LISTEN     0      128         :::111             :::*      users:(("rpcbind",1248,11))
LISTEN     0      128          *:111              *:*      users:(("rpcbind",1248,8))

Nadal nie ma identyfikatora procesu?

Są przypadki, w których po prostu nie ma PID powiązanego z używanym portem TCP. O NFS możesz przeczytać w odpowiedzi @ derobert , która jest jedną z nich. Są inni. Mam przypadki, w których używam tuneli ssh do łączenia się z usługami takimi jak IMAP. Są one również wyświetlane bez identyfikatora procesu.

W każdym razie możesz użyć bardziej szczegółowej formy, netstatktóra może rzucić dodatkowe światło na to, jaki proces ostatecznie korzysta z portu TCP.

$ netstat --program --numeric-hosts --numeric-ports --extend

Przykład

$ netstat --program --numeric-hosts --numeric-ports --extend |grep -- '-' | head -10
Proto Recv-Q Send-Q Local Address               Foreign Address             State       User       Inode      PID/Program name   
tcp        0      0 192.168.1.103:936           192.168.1.3:60526           ESTABLISHED root       160024310  -                   
tcp        0      0 192.168.1.1:2049            192.168.1.3:841             ESTABLISHED sam        159941218  -                   
tcp        0      0 127.0.0.1:143               127.0.0.1:57443             ESTABLISHED dovecot    152567794  13093/imap-login    
tcp        0      0 192.168.1.103:739           192.168.1.3:2049            ESTABLISHED root       160023970  -                   
tcp        0      0 192.168.1.103:34013         192.168.1.3:111             TIME_WAIT   root       0          -                   
tcp        0      0 127.0.0.1:46110             127.0.0.1:783               TIME_WAIT   root       0          -                   
tcp        0      0 192.168.1.102:54891         107.14.166.17:110           TIME_WAIT   root       0          -                   
tcp        0      0 127.0.0.1:25                127.0.0.1:36565             TIME_WAIT   root       0          -                   
tcp        0      0 192.168.1.1:2049            192.168.1.6:798             ESTABLISHED tammy      152555007  -             

Jeśli zauważysz, że dane wyjściowe zawierają INODES, abyśmy mogli wrócić do procesu przy użyciu tych informacji.

$ find -inum 152555007

Który pokaże ci plik, który może doprowadzić cię do procesu.

Bibliografia

• Port do PID

Inną opcją jest to, że gniazdo nie należy do procesu, należy do jądra. Jednym z typowych tego przykładów jest NFS.

Watt:~# netstat -ltp | egrep -- '-[[:space:]]*$'
tcp        0      0 *:nfs                   *:*                     LISTEN      -               
tcp        0      0 *:48131                 *:*                     LISTEN      -               
tcp6       0      0 [::]:55607              [::]:*                  LISTEN      -               
tcp6       0      0 [::]:nfs                [::]:*                  LISTEN      -               

Ogólnie nie jestem pewien, czy to dobry sposób na ich identyfikację. W konkretnym przypadku NFS rpcinfoczęsto będziemy mogli powiedzieć:

anthony@Watt:~$ rpcinfo -p | grep 48131
    100021    1   tcp  48131  nlockmgr
    100021    3   tcp  48131  nlockmgr
    100021    4   tcp  48131  nlockmgr

Niestety działa to tylko w przypadku IPv4. Aby uzyskać wersję v6, musisz przerwać -p, która następnie wyświetla numery portów w niemądry sposób: Jako dwa dodatkowe oktety adresu IP. Port 55607 staje się w ten sposób 217,55 (ponieważ 217  × 256 +  55  = 55607):

anthony@Watt:~$ rpcinfo  | grep -i 217.55
    100021    1    tcp6      ::.217.55              nlockmgr   superuser
    100021    3    tcp6      ::.217.55              nlockmgr   superuser
    100021    4    tcp6      ::.217.55              nlockmgr   superuser