Как определить процесс, у которого нет pid?

У меня есть процесс, который прослушивает 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

Но это ничего не возвращает. Это новая установка squeeze, и я действительно не знаю, что это может быть за процесс. Любая идея ?

ОТВЕТ Благодаря вашим комментариям я узнал, что это было. Я удалил nfs-сервер nfs-common (после dkpg --get-selections | grep nfs search), и неизвестный процесс исчез. Странно, что процессы ядра никак не помечены.

Еще раз спасибо вам обоим. ;)

networking security process

— Джон Доу
источник

Ответы:

NetStat

Там есть процесс, ваш ID пользователя просто не знаком с тем, что это такое. Это уровень защиты, 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

— ОДС
источник

@derobert - я думал, что это были темы.

— SLM

Потоки @slm (userspace) имеют PID.

— Дероберт

@derobert - это то, что я думал, но это была двойная проверка, чтобы быть уверенным.

— slm

@derobert - я нашел это: «Само ядро Linux предоставляет NFS-сервер (он же« knfsd »). Таким образом, нет связанного процесса, потому что ядро не является процессом».

— SLM

@JohnDoe - возможно, они связаны с NFS.

— Slm

Другой вариант заключается в том, что сокет не принадлежит процессу, он принадлежит ядру. Одним из распространенных примеров этого является 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

— derobert
источник

Спасибо, что указали, rpcinfo -pработает только для IPv4

— youfu