หมายเลขลิงก์ / proc / PID / fd / X


36

ใน Linux /proc/PID/fd/Xลิงก์สำหรับตัวอธิบายไฟล์ที่เป็นไพพ์หรือซ็อกเก็ตจะมีตัวเลขเช่น:

l-wx------ 1 user user 64 Mar 24 00:05 1 -> pipe:[6839]
l-wx------ 1 user user 64 Mar 24 00:05 2 -> pipe:[6839]
lrwx------ 1 user user 64 Mar 24 00:05 3 -> socket:[3142925]
lrwx------ 1 user user 64 Mar 24 00:05 4 -> socket:[3142926]
lr-x------ 1 user user 64 Mar 24 00:05 5 -> pipe:[3142927]
l-wx------ 1 user user 64 Mar 24 00:05 6 -> pipe:[3142927]
lrwx------ 1 user user 64 Mar 24 00:05 7 -> socket:[3142930]
lrwx------ 1 user user 64 Mar 24 00:05 8 -> socket:[3142932]
lr-x------ 1 user user 64 Mar 24 00:05 9 -> pipe:[9837788]

กดไลค์บนบรรทัดแรก: 6839 หมายเลขนั้นคืออะไร?

คำตอบ:


36

นั่นคือหมายเลขไอโหนดสำหรับไพพ์หรือซ็อกเก็ตที่เป็นปัญหา

ไปป์เป็นช่องทางเดียวที่มีปลายเขียนและปลายอ่าน ในตัวอย่างของคุณดูเหมือนว่า FD 5 และ FD 6 กำลังคุยกันเนื่องจากตัวเลขไอโหนดเหมือนกัน (อาจจะไม่ใช่ดูด้านล่าง)

สิ่งที่พบได้บ่อยกว่าการเห็นโปรแกรมที่พูดกับตัวเองเหนือไพพ์เป็นคู่ของโปรแกรมที่แยกกันพูดคุยกันโดยทั่วไปแล้วเพราะคุณตั้งค่าไพพ์ระหว่างพวกเขาด้วยเชลล์:

shell-1$ ls -lR / | less

จากนั้นในหน้าต่างเทอร์มินัลอื่น:

shell-2$ ...find the ls and less PIDs with ps; say 4242 and 4243 for this example...
shell-2$ ls -l /proc/4242/fd | grep pipe
l-wx------ 1 user user 64 Mar 24 12:18 1 -> pipe:[222536390]
shell-2$ ls -l /proc/4243/fd | grep pipe
l-wx------ 1 user user 64 Mar 24 12:18 0 -> pipe:[222536390]

สิ่งนี้บอกว่าเอาต์พุตมาตรฐานของ PID 4242 (FD 1 ตามแบบแผน) เชื่อมต่อกับไพพ์ที่มีหมายเลขไอโหนด 222536390 และอินพุตมาตรฐานของ PID 4243 (FD 0) นั้นเชื่อมต่อกับไพพ์เดียวกัน

ทั้งหมดนี้เป็นวิธีที่ยาวในการบอกว่าlsเอาต์พุตนั้นกำลังถูกส่งไปยังlessอินพุตของ

เมื่อกลับมาที่ตัวอย่างของคุณ FD 1 และ FD 2 แทบจะไม่ได้พูดคุยกัน เป็นไปได้มากว่านี่คือผลลัพธ์ของการคาด stdout (FD 1) และ stderr (FD 2) ด้วยกันดังนั้นพวกเขาทั้งคู่จึงไปยังปลายทางเดียวกัน คุณสามารถทำสิ่งนี้ได้ด้วยเชลล์เป้าหมายเช่นนี้:

$ some-program 2>&1 | some-other-program

ดังนั้นถ้าคุณแหย่เข้าไป/proc/$PID_OF_SOME_OTHER_PROGRAM/fdคุณจะพบ FD ที่สามติดกับไพพ์ที่มีหมายเลขไอโหนดเดียวกันกับที่แนบมากับ FDs 1 และ 2 สำหรับsome-programอินสแตนซ์ นี่อาจเป็นสิ่งที่เกิดขึ้นกับ FDs 5 และ 6 ในตัวอย่างของคุณ แต่ฉันไม่มีทฤษฎีที่พร้อมว่า FDs ทั้งสองนี้มารวมกันอย่างไร คุณต้องรู้ว่าโปรแกรมกำลังทำอะไรอยู่ภายในเพื่อหาว่า


1
ตัวอย่างเช่นฉันคิดว่าpidgin- มีท่อและซ็อกเก็ตจำนวนมากและสิ่งอื่น ๆ ดังนั้นจึงเป็นตัวอย่างที่ดี คำถามสุดท้ายหนึ่งข้อ: inodes มีความเฉพาะในบริบทของระบบไฟล์เฉพาะใช่ไหม? ในขณะที่ฉันสามารถมี inode 3 ใน/ระบบไฟล์ของฉันและอื่น ๆ (แตกต่าง) inode 3 ใน/bootระบบไฟล์ของฉัน
Thanatos

4
ใช่. ในกรณีของ/procระบบไฟล์หมายเลขไอโหนดจะถูกสร้างขึ้นทันที (ดูget_next_ino()ในfs/inode.cเคอร์เนล) เริ่มต้นจาก 0 เมื่อระบบถูกบูทใหม่ กลไกที่ทำให้เกิดขึ้นนั้นใช้ร่วมกันโดยระบบไฟล์ที่ไม่สามารถใช้งานได้หลายระบบของลินุกซ์ (proc, configfs, ramfs, autofs ... ) ซึ่งหมายเลขไอโหนดนั้นไม่ซ้ำกันแม้ว่า POSIX semantics จะไม่ต้องการมัน เป็นกรณีที่ค่อนข้างพิเศษอย่างไรก็ตาม โดยทั่วไปกฎที่คุณกำลังพูดถึงนั้นอ้างอิงในการเชื่อมต่อกับระบบไฟล์แบบถาวรเช่น ext3
Warren Young

33

ซ็อกเก็ตสำหรับคุณสามารถหาข้อมูลเพิ่มเติมเกี่ยวกับไอโหนดใน/proc/net/tcp, หรือ/proc/net/udp /proc/net/unixตัวอย่างเช่น:

ls -l /proc/<pid>/fd
lrwx------ 1 root root 64 May 26 22:03 3 -> socket:[53710569]

เราเห็นไอโหนดคือ 53710569

head -n1 < tcp ; grep -a 53710569 tcp
sl  local_address rem_address   st tx_queue rx_queue tr tm->when retrnsmt   uid  timeout inode                   
155: 0100007F:001B 00000000:0000 0A 00000000:00000000 00:00000000 00000000  0        0 53710569 1 ffff88011f52c200 300 0 0 2 -1

ในกรณีนี้นี่คือซ็อกเก็ตการฟัง (ไม่มีที่อยู่ระยะไกล) ฟังบนพอร์ตท้องถิ่น 27 (0x1B) ที่อยู่ IP มี 4 ไบต์เป็นเลขฐานสิบหกใน "สัญกรณ์เครือข่าย" คุณสามารถใช้inet_ntoaฟังก์ชันเพื่อแปลงเป็นเครื่องหมายย่อ abcd มาตรฐาน (127.0.0.1 ในกรณีนี้)

โปรดทราบว่าไฟล์เหล่านี้ดูเหมือนจะเป็น 0 ไบต์ แต่มีเนื้อหาหากคุณอ่าน นอกจากนี้โปรดทราบว่า-aจำเป็นต้องใช้กับ grep เนื่องจากอาจ (เช่นกับunix) เป็นไบนารี


นอกจากนี้ยังมี/proc/net/tcp6และ/proc/net/udp6สำหรับ IPv6
Craig McQueen
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.