จะระบุกระบวนการที่ไม่มี pid ได้อย่างไร?


47

ฉันมีกระบวนการที่ฟัง 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 -i TCP:45136

แต่มันจะไม่คืนสิ่งใดเลย มันเป็นการติดตั้งแบบใหม่ของการบีบและฉันไม่รู้จริงๆว่ากระบวนการนี้เป็นอย่างไร ความคิดใด ๆ

ตอบ ขอบคุณความคิดเห็นของคุณฉันพบว่ามันคืออะไร ฉันยกเลิกการติดตั้ง nfs-server nfs-common (หลังจาก dkpg --get-selections | grep nfs search) และกระบวนการที่ไม่รู้จักหายไป แปลกแม้ว่ากระบวนการเคอร์เนลจะไม่ถูกทำเครื่องหมาย แต่อย่างใด

ขอขอบคุณอีกครั้งสำหรับคุณทั้งคู่ ;)

คำตอบ:


57

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

เอสเอส

หากคุณไม่มีโชคด้วย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))

ID กระบวนการยังไม่อยู่ที่นั่นหรือ

มีบางครั้งที่ไม่มี PID ที่เชื่อมโยงกับพอร์ต TCP ที่ใช้งานอยู่ คุณสามารถอ่านเกี่ยวกับ NFS ในคำตอบของ @ derobertซึ่งเป็นหนึ่งในนั้น มีคนอื่น ๆ ฉันมีอินสแตนซ์ที่ฉันใช้ ssh tunnels เพื่อเชื่อมต่อกลับไปยังบริการต่าง ๆ เช่น IMAP สิ่งเหล่านี้จะปรากฏขึ้นโดยไม่มี ID กระบวนการด้วย

ในกรณีใด ๆ คุณสามารถใช้รูปแบบ verbose เพิ่มเติม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

ซึ่งจะแสดงไฟล์ซึ่งอาจนำคุณไปสู่กระบวนการ

อ้างอิง


@derobert - ฉันคิดว่าพวกเขาเป็นหัวข้อ
slm

@slm (userspace) เธรดมี PID
Derobert

@derobert - นั่นคือสิ่งที่ฉันคิด แต่ก็ต้องตรวจสอบอีกครั้งเพื่อให้แน่ใจ
slm

@derobert - ฉันพบสิ่งนี้: "เคอร์เนล Linux จัดเตรียมเซิร์ฟเวอร์ NFS (aka" knfsd ") ดังนั้นจึงไม่มีกระบวนการที่เกี่ยวข้องเนื่องจากเคอร์เนลไม่ใช่กระบวนการ"
slm

@JohnDoe - อาจเป็นเพราะพวกเขาเกี่ยวข้องกับ NFS
slm

16

อีกตัวเลือกหนึ่งคือซ็อกเก็ตไม่ได้อยู่ในกระบวนการ แต่เป็นของเคอร์เนล ตัวอย่างทั่วไปอย่างหนึ่งของสิ่งนี้คือ 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

1
ขอบคุณที่ชี้ให้เห็นว่าrpcinfo -pใช้ได้เฉพาะกับ IPv4
youfu
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.