Розетки, знайдені 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, але це також не дало результатів.

В якості фону, додаток є контейнером для декількох завдань, які, крім іншого, виконують мережеві дзвінки. Мені потрібно виділити ту, що йде на берсерк, але поки я не дізнаюся, з ким спілкуються ці розетки, я застряг.

Це може статися, якщо ви створили сокет, але ніколи не з'єднуйтеся з ним () або зв'язуйте (). Вашою найкращою ставкою може бути напруження програми (-fF), а потім перехресне посилання з результатом lsof, щоб визначити, які сокети викликають проблему. Як бонусний метод налагодження: якщо ви загортаєте дзвінки в сокет з інформацією про налагодження і записуєте їх у / dev / null, він з’явиться в напрузі, не даючи вам весело великих журнальних файлів.

Використовуючи 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 для кліпу) - найкращий інструмент, щоб побачити, як використовуються ці розетки. Wireshark допоможе вам розбити тип трафіку, який перекидається через дріт. Цілком ймовірно, що перші кілька підключень матимуть успіх, а потім вони досягнуть межі дескриптора файлу. Після того, як буде досягнуто обмеження дескриптора файлу, Wireshark не збирається брати нічого (а точніше є netstat для цього питання), але це допоможе звузити проблему. Можливо, існує випадок, коли надсилається багато вихідних SYN, однак не надходить жодне SYN / ACK, тому багато з'єднань tcp просто застрягли в стані SYN_WAIT.

Якщо у вас є доступ до вихідного коду і ви знаєте тип створюваних сокетів (наприклад, за допомогою strace або просто пошук коду), ви можете відкрити проект у Eclipse (або іншому IDE) і встановити точку перерви у функції, яка створює ці розетки. Коли точка зламу потрапить, тоді ви можете подивитися на слід стека. Цей дескриптор файлу протікає, можливо, простий нескінченний цикл або, можливо, значення часу очікування сокета занадто велике. Інша можливість полягає в тому, що програма java не робить socket.close()для очищення з'єднань. Закриття зазвичай робиться в finelyблоці try/catch(Так, у сокеті завжди має бути спроба / ловити на Java, інакше він не будується :). Зрештою, ймовірно, що програма Java не належним чином обробляє IOException.