ซ็อกเก็ตที่พบโดย lsof แต่ไม่ใช่โดย netstat

ฉันมีแอปพลิเคชั่นที่ไม่มีตัวให้คำอธิบายไฟล์ปรากฏอยู่โดยเปิดซ็อกเก็ต แต่ฉันไม่สามารถหาได้ว่าซ็อกเก็ตเหล่านี้ทำอะไร เหล่านี้ปรากฏในผลลัพธ์ lsof เป็น

java    9689 appuser 1010u  sock       0,5          263746675 can't identify protocol
java    9689 appuser 1011u  sock       0,5          263746676 can't identify protocol
java    9689 appuser 1012u  sock       0,5          263746677 can't identify protocol
java    9689 appuser 1014u  sock       0,5          263746678 can't identify protocol
java    9689 appuser 1015u  sock       0,5          263746679 can't identify protocol
java    9689 appuser 1016u  sock       0,5          263746681 can't identify protocol

และใน / proc / $ PID / fd เป็น

lrwx------ 1 appuser appuser 64 Jun 23 11:49 990 -> socket:[263732085]
lrwx------ 1 appuser appuser 64 Jun 23 11:49 991 -> socket:[263732086]
lrwx------ 1 appuser appuser 64 Jun 23 11:49 992 -> socket:[263735307]
lrwx------ 1 appuser appuser 64 Jun 23 11:49 993 -> socket:[263732088]
lrwx------ 1 appuser appuser 64 Jun 23 11:49 995 -> socket:[263735308]
lrwx------ 1 appuser appuser 64 Jun 23 11:49 996 -> socket:[263735309]
lrwx------ 1 appuser appuser 64 Jun 23 11:49 997 -> socket:[263745434]
lrwx------ 1 appuser appuser 64 Jun 23 11:49 998 -> socket:[263745435]
lrwx------ 1 appuser appuser 64 Jun 23 11:49 999 -> socket:[263745436]

netstat -aแต่ไม่มีการส่งออกที่คล้ายกันใน

ซ็อกเก็ตเหล่านี้คืออะไรและฉันจะทราบได้อย่างไรว่าพวกเขาทำอะไร

แก้ไข : ฉันได้ลองใช้งานgrep $SOCKET /proc/netตามที่แนะนำใน lsof FAQโดยที่ $ SOCKET เป็นอินสแตนซ์ 263746679 แต่นั่นก็ไม่ได้ผลลัพธ์

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

สิ่งนี้สามารถเกิดขึ้นได้หากคุณสร้างซ็อกเก็ต แต่ไม่เคยเชื่อมต่อ () หรือผูก () ด้วย ทางออกที่ดีที่สุดของคุณคือ strace (-fF) แอปพลิเคชันจากนั้นจึงอ้างอิงข้ามกับเอาต์พุตของ lsof เพื่อพิจารณาว่าซ็อกเก็ตใดที่ทำให้เกิดปัญหา เป็นวิธีโบนัสในการดีบั๊ก: ถ้าคุณตัดการเรียกซ็อกเก็ตของคุณด้วยข้อมูลการดีบักและเขียนออกไปที่ / dev / null มันจะปรากฏใน strace โดยไม่ให้ไฟล์บันทึกที่มีขนาดใหญ่มาก

เมื่อใช้ Python ฉันพบปัญหาเดียวกันกับซ็อกเก็ต SSL:

• เมื่อฉันใช้ socket.close () ซ็อกเก็ตยังคงอยู่ในสถานะ CLOSE_WAIT เป็นเวลาไม่ จำกัด
• เมื่อฉันใช้ socket.shutdown () lsof พูดว่า "ไม่สามารถระบุโปรโตคอล"

ทางออกคือการแกะเลเยอร์ SSL ก่อนปิด:

• origsock = socket.unwrap ()
• origsock.close ()

นี่เป็นการปิดซ็อกเก็ตอย่างเหมาะสมในแอพของฉัน

สิ่งแรกที่ฉันจะทำคือเพิ่มถ้าขีด จำกัด ตัวอธิบายไฟล์ของคุณ:

~# vi /etc/sysctl.conf
fs.file-max = 331287

ต่อไปฉันจะตรวจสอบให้แน่ใจว่าระบบของคุณทันสมัยแล้วซึ่งรวมถึงไลบรารีและเซิร์ฟเวอร์ทั้งหมด อาจเป็นไปได้ว่าเซิร์ฟเวอร์แอปพลิเคชัน Java ของคุณล้าสมัย (หากคุณใช้) นอกจากนี้ยังมีความเป็นไปได้ที่แอปพลิเคชันเซิร์ฟเวอร์ของคุณจะถูกกำหนดค่าผิดพลาดคุณควรดูที่ไฟล์กำหนดค่าของคุณและลดระดับconnectionTimeoutและ / หรือของคุณลงmaxKeepAliveRequests(ฉันไม่แน่ใจว่าแอพพลิเคชันเซิร์ฟเวอร์ของคุณกำลังใช้งานอยู่หรือไม่

ฉันไม่แน่ใจว่าแอปพลิเคชั่นนี้ทำอะไร แต่ถ้าคุณไม่คิดว่ามันต้องใช้ซ็อกเก็ตนับหมื่นซ็อกเก็ตนี่ก็เกือบจะเป็น"ตัวบ่งชี้ไฟล์รั่วไหล"ในแอปพลิเคชัน Java ของคุณ คุณอาจต้องส่งรายงานข้อผิดพลาดไปยังผู้ขาย ในรายงานข้อผิดพลาดนี้คุณควรรวมข้อมูลเกี่ยวกับวิธีการสร้างปัญหาขึ้นใหม่

ต่อไปนี้เป็นวิธีแก้ไขข้อบกพร่องของปัญหา

Wireshark (หรือ twireshark สำหรับ cli) เป็นเครื่องมือที่ดีที่สุดเพื่อดูว่ามีการใช้ซ็อกเก็ตเหล่านี้อย่างไร Wireshark จะให้คุณแยกประเภทของการจราจรที่ถูกโยนข้ามลวด เป็นไปได้ว่าการเชื่อมต่อสองสามครั้งแรกจะประสบความสำเร็จจากนั้นจะถึงขีด จำกัด ตัวอธิบายไฟล์ เมื่อขีด จำกัด ตัวอธิบายไฟล์ถูกโจมตี Wireshark จะไม่ไปรับสิ่งใด (และ neater เป็น netstat สำหรับเรื่องนั้น) แต่สิ่งนี้จะช่วย จำกัด ปัญหาให้แคบลง อาจมีกรณีที่มีการส่งออก SYN จำนวนมาก แต่ไม่มีการรับ SYN / ACKs ดังนั้นการเชื่อมต่อ tcp จำนวนมากจึงติดอยู่ในสถานะ SYN_WAIT

หากคุณมีการเข้าถึงซอร์สโค้ดและคุณรู้ประเภทของซ็อกเก็ตที่ถูกสร้างขึ้น (เช่นการใช้ strace หรือเพียงแค่ค้นหารหัส) จากนั้นคุณสามารถเปิดโครงการใน Eclipse (หรือ IDE อื่น) และตั้งจุดพักที่ฟังก์ชันที่ กำลังสร้างซ็อกเก็ตเหล่านี้ เมื่อเบรกพอยต์โดนกระทบคุณสามารถดูการติดตามสแต็กได้ ไฟล์ descriptor นี้รั่วได้อาจเป็น infinite loop หรือค่า timeout ของ socket นั้นใหญ่เกินไป ความเป็นไปได้อีกอย่างหนึ่งคือแอป java ไม่ได้ทำการsocket.close()ล้างข้อมูลการเชื่อมต่อ การปิดจะกระทำโดยทั่วไปในfinelyบล็อกของ a try/catch(ใช่ซ็อกเก็ตต้องมีการลอง / จับใน Java เสมอมิเช่นนั้นจะไม่สร้าง :) ในตอนท้ายของวันมีแนวโน้มว่าแอป Java ไม่จัดการ IOException อย่างถูกต้อง