Вопросы Теги

Непрекращающееся соединение TCP в СЛУШАЕТ состояние

Возможно, это - проявление той же проблемы, описанной здесь:

Обходное решение для выполнения сервера VNC в Windows Vista

Проблемы вызываются Windows Vista новое средство защиты под названием Сессия 0 Изоляции. Предыдущие версии Windows выполнили системные службы на той же сессии входа в систему как локально зарегистрированный пользователь (Сессия 0). В Windows Vista Сессия 0 теперь резервируется для этих сервисов, и все интерактивные логины сделаны на других сессиях, вызвав сервер VNC, не могущий принять входящий дистанционный запрос на установление соединения.

и предлагаемое решение:

Таким образом, для создания сервера VNC на работах Windows Vista правильно, разрешение обходного решения (по крайней мере, пока разработчики VNC для выпуска надлежащей фиксации или обновления для обращения к новому ограничению безопасности в Windows Vista) состоит в том, чтобы выполнить сервер VNC в непривилегированном режиме.

Или попробуйте, если это работает с UltraVNC.

P.S.: Вот статья MSDN о Совместимости приложения: Сессия 0 Изоляции.

0
задан 18 March 2010 в 18:33
5 ответов

Так как Вы только делаете это вручную, Вам, вероятно, придется добавить другую проверку. 

netstat -p

и уничтожьте pid, связанный с Вашим открытым сокетом, даже если это - удар или sh.

Кроме того, Вы упомянули это большую часть времени работы SIGTERM. Если это так, Ваше приложение должно поймать SIGTERM и вскочить в некоторый корректный код выхода что RSTs все открытые соединения и затем закрывает сокет.

HTH

1
ответ дан 4 December 2019 в 11:38
  • 1
    Это могло быть путем, к сожалению, мое приложение won' t смочь поймать любой сигнал. Причина я должен уничтожить его, состоит в том, потому что после броска OutOfMemoryError jvm в основном становится нестабильным и не способный выполнить код правильно –  Silvio Donnini 18 March 2010 в 17:59
  • 2
    I' m собирающийся пытаться уничтожить каждый процесс, который хватает сокета слушания, только чтобы видеть если that' s проблема –  Silvio Donnini 18 March 2010 в 18:21
  • 3
    @Silvio - просто предположение здесь... Я думаю, потому что Вы запускаете свое jvm приложение с оболочки, it' s показывающий основным процессом. (Вы могли проверить с pstree, когда приложение Java работает.), когда ребенок умирает, сокет наследован процессом sh... –  Scott Lundberg 18 March 2010 в 18:41
  • 4
    Это имело бы смысл, но я сверился с pstree, как Вы сказали, и it' s прямой ребенок init не sh –  Silvio Donnini 18 March 2010 в 18:56
  • 5
    @Silvio. Не уверенный, как процесс sh получает сокет затем... Вы делающий любой вид c' кодирование типа выхода с разветвлением, куда pid передается? –  Scott Lundberg 18 March 2010 в 19:18

Сервер все еще ожидает некоторые пакеты от клиентов после того, как сокеты слушания будут закрыты, и сохраняет порт присвоенным. Приложение может использовать опцию сокета SO_REUSEADDR позволить непосредственное повторное использование адреса сокета.

Вот выборка от моего IP Linux (7) страница руководства:

Локальный адрес сокета TCP, который был связан, недоступен в течение некоторого времени после закрытия, если флаг SO_REUSEADDR не был установлен. Необходимо соблюдать осторожность при использовании этого флага, поскольку это делает TCP менее надежным.

Сервер приложений или сервер приложений могли бы иметь параметр конфигурации для использования этой опции сокета.

3
ответ дан 4 December 2019 в 11:38
  • 1
    хм, обратите особое внимание на , Необходимо соблюдать осторожность при использовании этого флага, поскольку это делает TCP менее надежным молитва Системного администратора: don' t решают одну проблему путем повреждения чего-то еще. –  The Unix Janitor 18 March 2010 в 17:08
  • 2
    В этом случае it' s прекрасный. Прочтение netstat вывод почти наверняка показал бы, что сокет находится в TIME_WAIT, который только имел бы значение, был ли все еще шанс, что что-то полезное могло прибыть в сокет. Так как приложение, которое обработало бы ту информацию, уже мертво, она doesn' t имеют значение если it' s снова использованный. –  Insyte 18 March 2010 в 17:44
  • 3
    Я добавил вывод netstat сейчас, я должен был включать его с самого начала. Это, кажется, не находится в состоянии TIME_WAIT, но всегда в СЛУШАЮТ –  Silvio Donnini 18 March 2010 в 17:52

Ваш не на самом деле уничтожение Вашего JAVA-приложения, Вашего на самом деле уничтожения Вашей виртуальной машины Java (jvm) экземпляр, который в свою очередь запускает Ваше JAVA-приложение.

Это не идея способ завершить Ваш процесс Java.

если то, что вы имели необходимость уничтожить Ваш jvm с уничтожением-9, jvm привычка может, разрешают после себя таким образом оставляющий операционные ресурсы в неопределенности.:-(

Добавьте некоторую функциональность к своему приложению, чтобы заставить его выйти корректно. Если у Вас нет выбора, то попытайтесь уничтожить Вас jvm с-15, он может помочь ему разрешить после себя.

Если Ваша программа Java действительно подвешивает jvm, то необходимо получить отладчик и раздавить тех вредителей.

Уничтожение процесса и перезапуск его являются взломом, but's не фиксируют. Необходимо только использовать SIGKILL, если процесс не отвечает никакой другой метод.

Я обычно пробую

уничтожьте-15

затем только уничтожьте-9 как последнее прибежище.

и для забавы...

http://www.youtube.com/watch?v=Fow7iUaKrq4

1
ответ дан 4 December 2019 в 11:38
  • 1
    Да, но это не способ, которым я обычно выхожу из своего приложения. Это - то, в случае, если чрезвычайная ситуация происходит (т.е. OutOfMemoryError), и я сначала пытаюсь уничтожить ее с SIGTERM, который всегда успешно выполняется. Если это когда-либо уничтожает-15 сбоев, я обращаюсь к вызову его с-9, но это никогда не было необходимо –  Silvio Donnini 18 March 2010 в 17:32

С Вашим обновлением у меня есть другое объяснение. Процесс sh, сохраняющий открытый сокет, должен быть ребенком Вашего приложения, разветвленного после того, как сокет слушания был открыт. Это не умерло со своим родителем и было принято процессом init.

Необходимо попытаться узнать то, что то, что оболочка обрабатывает для (вероятно, некоторый сценарий, запущенный приложением) и почему это не завершается. Возможно, будет достаточно исправить сценарий, таким образом, это завершится после окончания его, задание будет достаточно? Или существует способ заставить его не отсоединиться от родителя (это должно умереть с родителем, если часть той же группы процесса), или доберитесь близко до всех ненужных дескрипторов файлов, наследованных от родителя.

Можно попробовать:

fuser -p $pid_of_the_sh_process

видеть то, что другие файлы это сохраняет открытым. Один из них будет, по всей вероятности, сценарием оболочки. Знание, что это, мы можем найти способ решить проблему.

0
ответ дан 4 December 2019 в 11:38

Если у Вас есть доступ к исходному коду, необходимо создать сокет с SO_REUSEADDR опция упоминается Jacek. Также интереса tcp_tw_recycle и tcp_tw_reuse флаги ядра (на Linux).

Настоящая проблема находится в дизайне протокола, который Вы можете или не мочь изменять. Интересные потоки по теме:

0
ответ дан 4 December 2019 в 11:38

Теги

Похожие вопросы