Вопросы Теги

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

Короче говоря, Вы хотите что-то как

xrandr --output LVDS --scale 1.28x1.28

(замена LVDS с желаемым выходным именем, как замечено в выводе выполнения xrandr отдельно).

Попробуйте. Некоторые сайты сказали, что это не работает над некоторыми системами, которые используют KMS (установка привилегированного режима); если так, это - ошибка, это, надо надеяться, фиксируется. См. эти ссылки еще для некоторой информации об использовании xrandr масштабировать экран как это:

48
27.10.2013, 06:33
2 ответа

netstat

Существует процесс там, Ваш идентификатор пользователя просто не посвящен в наблюдение, каково это. Это - слой защиты, обеспеченной lsof это мешает Вам видеть это. Просто повторно выполните команду, но снабдите префиксом ее с помощью sudo команда вместо этого.

$ sudo netstat -antlp | grep 45136

Существует даже предупреждение об этом в выводе lsof наверху.

(Не все процессы могли быть определены, не находящуюся в собственности информацию о процессе не покажут, необходимо было бы быть корнем для наблюдения всего этого.)

Пример

$ 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

Если у Вас нет удачи с 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

Который покажет Вам файл, который мог бы привести Вас к процессу.

Ссылки

61
27.01.2020, 19:34
  • 1
    @derobert - Я думал, что они были потоками. (пространство пользователя) –  slm♦ 27.10.2013, 06:04
  • 2
    @slm потоки имеет PIDs. –  derobert 27.10.2013, 06:05
  • 3
    @derobert - это - то, что я думал, но проверял дважды, чтобы быть уверенным. –  slm♦ 27.10.2013, 06:05
  • 4
    @derobert - Я нашел это: "Само ядро Linux обеспечивает сервер NFS (иначе "knfsd"). Таким образом нет никакого связанного процесса, потому что ядро не является процессом". –  slm♦ 27.10.2013, 06:10
  • 5
    @JohnDoe - могло бы случиться так, что они связаны с NFS. –  slm♦ 27.10.2013, 06:12

Другая опция состоит в том, что сокет не принадлежит процессу, он принадлежит ядру. Одним типичным примером этого является 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
18
27.01.2020, 19:34
  • 1
    Спасибо за указание rpcinfo -p только работы для удара IPv4 –  youfu 09.07.2017, 07:09

Теги

Похожие вопросы