Soketler lsof tarafından bulundu ancak netstat tarafından bulunmadı

Görünüşe göre yuvaları açarak dosya tanımlayıcıları biten bir uygulama var, ama tam olarak bu yuvaların ne olduğunu bulamıyorum. Bunlar lsof çıktısında şu şekilde görünür:

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

ve / proc / $ PID / fd biçiminde

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]

ancak benzer bir çıktı yok netstat -a.

Bu soketler nedir ve ne yaptıklarını nasıl öğrenebilirim?

Düzenleme : $ SOCKET örneğin 263746679 olduğu lsof SSS , grep $SOCKET /proc/nettavsiye edildiği gibi çalışmayı denedim , ama bu da sonuç vermedi.

Arka plan olarak, uygulama, diğerlerinin yanı sıra, ağ aramaları yapan birden çok görev için bir kapsayıcıdır. Çılgına döneni seçmeliyim, ama bu soketlerin kiminle iletişim kurduğunu öğrenene kadar sıkıştım.

Bu, bir soket oluşturursanız, ancak asla sokete () veya bind () bağlamazsanız oluşabilir. En iyi seçeneğiniz, uygulamayı zorlamak (-fF) ve daha sonra soruna hangi soketlerin neden olduğunu belirlemek için lsof çıktısıyla çapraz referans olabilir. Hata ayıklama için bir bonus yöntemi olarak: soket çağrılarınızı hata ayıklama bilgileriyle sararsanız ve / dev / null dosyasına yazarsanız, size çok büyük günlük dosyaları vermeden şeritte görünür.

Python kullanarak, SSL soketlerinde aynı sorunla karşılaştım:

• Socket.close () kullandığımda, yuva süresiz olarak CLOSE_WAIT durumunda kalır
• socket.shutdown () kullandığımda, lsof "protokolü tanımlayamıyor" diyor

Çözüm kapanmadan önce SSL katmanının paketini açmaktı:

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

Bu, uygulamamdaki yuvaları düzgün bir şekilde kapatır.

Dosya tanımlayıcı sınırınız varsa ilk yapacağım şey incrase.

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

Daha sonra sisteminizin güncel olduğundan emin olurum, bu tüm kütüphaneleri ve sunucuları içerir. Java uygulama sunucunuzun güncel olmaması mümkündür (eğer kullanıyorsanız). Ayrıca uygulama sunucunuzun yanlış yapılandırılmış olması, yapılandırma dosyanıza bakmanız connectionTimeoutve ve / veya maxKeepAliveRequestscihazınızı düşürmeniz (hangi uygulama sunucusunu kullandığınızdan veya hiç kullanmıyorsanız ...) emin değilsiniz.

Bu uygulamanın ne yaptığından emin değilim, ancak on binlerce soket gerektirdiğini düşünmüyorsanız, bu neredeyse kesinlikle Java uygulamanızda bir "dosya tanımlayıcı sızıntısı" dır . Satıcıya bir hata raporu göndermeniz gerekebilir. Bu hata raporuna, sorunun nasıl yeniden oluşturulacağı hakkında bilgi eklemelisiniz.

İşte sorunu ayıklamanın bazı yolları.

Wireshark (veya klips için twireshark), bu soketlerin nasıl kullanıldığını görmek için en iyi araçtır. Wireshark, telin üzerine atılan trafik türünün bir dökümünü verecektir. İlk birkaç bağlantının başarılı olması ve daha sonra dosya tanımlayıcı sınırına ulaşması muhtemeldir. Dosya tanımlayıcı sınırına ulaşıldıktan sonra Wireshark hiçbir şey almaz (ve daha neater bu konuda netstattır), ancak bu sorunu daraltmaya yardımcı olacaktır. Giden SYN'lerin gönderildiği bir durum olabilir, ancak hiçbir SYN / ACK alınmamaktadır, bu nedenle çok sayıda tcp bağlantısı SYN_WAIT durumunda kalmıştır.

Kaynak koda erişiminiz varsa ve yaratılan soket türünü biliyorsanız (strace kullanmak veya sadece kodu aramak gibi) projeyi Eclipse'de (veya başka bir IDE) açabilir ve işlevde bir kırılma noktası ayarlayabilirsiniz. bu soketleri yaratıyor. Kesme noktası vurulduğunda, yığın izlemesine bakabilirsiniz. Bu dosya tanımlayıcı sızıntısı basit bir sonsuz döngü olabilir ya da yuva zaman aşımı değeri çok büyük olabilir. Başka bir olasılık, java uygulaması socket.close()bağlantıları temizlemek için bir yapmıyor olmasıdır . Kapatma yapmak genellikle bir finelyblokta yapılır try/catch(Evet, bir soketin her zaman Java'da bir try / catch olması gerekir veya oluşturmaz :). Günün sonunda, Java uygulamasının IOException kurallarını düzgün işlememesi muhtemeldir.