Як визначити процес, який не має під?

У мене є процес, який слухають 2 порти: 45136 / tcp і 37208 / udp (насправді я припускаю, що це той самий процес). Але netstat не повертає жодного pid:

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

Той самий результат із "grep 37208".

Я також спробував lsof:

lsof -i TCP:45136

Але це нічого не повертає. Це нова установка стиску, і я справді не знаю, що може бути цим процесом. Будь-яка ідея?

ВІДПОВІДЬ Завдяки вашим коментарям я дізнався, що це таке. Я видалив nfs-сервер nfs-common (після пошуку dkpg --get-select | grep nfs search) і невідомий процес не зник. Дивно, хоча процеси ядра жодним чином не позначені.

Ще раз дякую обом. ;)

netstat

Там є процес, ваш користувальницький просто не є прихильним бачити, що це таке. Це шар захисту, який забезпечується тим, lsofщо ви не бачите цього. Просто перезапустіть команду, але sudoзамість неї додайте префікс за допомогою команди.

$ sudo netstat -antlp | grep 45136

Про це навіть є попередження у висновку lsofвгорі.

(Не всі процеси можуть бути ідентифіковані. Інформація про процес, що не належить, не відображатиметься. Вам потрібно буде мати root, щоб побачити все це.)

Приклад

$ 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

сс

Якщо вам не пощастить, netstatможливо, ssвийде. Вам все одно потрібно буде скористатися sudo, і вихід може бути трохи більш виразним.

Приклад

$ 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))

Ідентифікатор процесу все ще не існує?

Є випадки, коли просто не використовується PID, пов'язаний з портом TCP. Про NFS ви можете прочитати у відповіді @ derobert , яка є однією з них. Є й інші. У мене є випадки, коли я використовую ssh тунелі для підключення назад до таких служб, як IMAP. Вони відображаються і без ідентифікатора процесу.

У будь-якому випадку ви можете використовувати більш детальну форму, netstatяка може пролити додаткове світло на те, що в кінцевому підсумку використовується порт TCP.

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

Приклад

$ 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  -             

Якщо ви помітили, що результат включає INODES, щоб ми могли відстежувати процес, використовуючи цю інформацію.

$ find -inum 152555007

Це покаже вам файл, який може привести вас до процесу.

Список літератури

• Порт на PID

Інший варіант полягає в тому, що сокет не належить до процесу, він належить до ядра. Одним із поширених прикладів цього є 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      -               

Я не впевнений, хороший спосіб, загалом, їх визначити. У конкретному випадку NFS rpcinfoчасто зможе сказати нам:

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

На жаль, це працює лише для IPv4. Щоб отримати v6, вам доведеться звільнитись -p, який потім нерозумно відображає номери портів: Як два додаткові октети IP-адреси. Порт 55607, таким чином, стає 217,55 (тому що 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