TCP socket timeout problem

1) например, если после успешного выполнения three-way-handshake (или позднее по ходу жизни соединения, но когда одна сторона не ожидает приема данных) на сокете с включенным keepalive с нулевым интервалом, по какой-либо причине пакеты второй стороны не будут доходить до первой, то после определенного количества попыток вторая сторона решит, что соединение пропало и закроет его (или скажем если вторую сторону ребутнули по питанию и она не закрыла корректно соединение). при этом первая сторона все еще будет считать соединение открытым.

2) устанавливать SO_KEEPALIVE в ненулевое значение. Я так понимаю, что ситуация уже есть, тогда рекомендую перезапустить серверное приложение, это должно закрыть все TCPCB. /proc/net/ip_conntrack и cutter тут вообще ни при чем, это механизм netfilter.

Программисты, большая просьба. Концепции, как известно, текут, и концепция прозрачной сети течет очень сильно. Пожалуйста, читайте хотя бы Стивенса прежде чем пользоваться вызовом socket().

пардон, в вашем случае висит соединение на клиенте, вот его и надо kill().

если это все же ssh, то в конфиге опцию просто выставите и все.

общесистемно это делается через sysctl:

net.ipv4.tcp_keepalive_time
net.ipv4.tcp_keepalive_intvl
net.ipv4.tcp_keepalive_probes

net.ipv4.tcp_keepalive_intvl = 75 net.ipv4.tcp_keepalive_probes = 9 net.ipv4.tcp_keepalive_time = 7200

keepalive - не нулевое, но соединение до сих пор висит. Даже ifconfig eth0 down не помог

пакаж нетстат -пант

tcp 0 0 192.168.2.108:50523 10.100.0.5:22 ESTABLISHED 3438/java

Все дело в НАТе.

$ cat /etc/sysctl.conf
net.ipv4.tcp_keepalive_intvl = 10
net.ipv4.tcp_keepalive_probes = 3
net.ipv4.tcp_keepalive_time = 30

если можно - по подробней, текущая сессия висит уже 20 часов, и даже согласно моим настройкам должна уже отвалиться

sudo kill -9 3438

проблема в том что программу нельзя убивать, а также в том, что сокет трактуется программой как работающий, и не отваливается по таймауту

Коннект прошел, но ты об этом где-то забыл (потерял fd ?) Странно что на клиенте висяк, но в любом случае, промотри логику. Где-то получился эдакий дедлок.

Убить можно попробовать подключившись с gdb и call shutdown(..) / call close(..)

А как программа віясняет что сокет «рабочий» ? Пишет и читает ?

Да, пытается читать

Thread: http-0.0.0.0-8080-1 : priority:5, demon:true, threadId:1696, threadState:RUNNABLE, lockName:null

java.net.SocketInputStream.socketRead0(Native Method)
java.net.SocketInputStream.read(SocketInputStream.java:129)
org.apache.coyote.http11.InternalInputBuffer.fill(InternalInputBuffer.java:700)
org.apache.coyote.http11.InternalInputBuffer.parseRequestLine(InternalInputBuffer.java:366)
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:805)
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446)
java.lang.Thread.run(Thread.java:595)

> keepalive - не нулевое, но соединение до сих пор висит. Даже ifconfig eth0 down не помог.

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

Системные - не менялись, и как можно узнать текущие настройки?

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

он у тебя ничего не проверяет, он просто висит в сисколле read(). а чем вас это не устраивает - то что он будет так вечно висеть?

да, в другом потоке висит поток ожидающий данные(общение между ними реализованно на блокирующей очереди), и блокирующий работу остальной части системы

ну так пришли ему эти данные ;) а потом разорви соединение (или просто сразу разорви), и если твое приложение имеет нормальный error-handling оно просто его переоткроет.

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

1) сделанна на джибосе
2) не пойму причем здесь кластеризация
3) каким образом прислать данные? тред висит в одном из вызовов Ganymed SSH библиотеки, в приложении обработка ошибок есть. Проблема именно в том что доступ к соединению не отваливается

еще интересно, возможно ли подобную проблему воспроизвести намеренно

возможно

2) при том, что в кластере высокой доступности можно было бы просто потушить ноду.
3) сгенерировать пакет TCP RST с правильными параметрами источника и получателя (IP/port) и sequence number.

sequence number как предлагаете искать?

перебором - самый простой способ.

если хочется экстрима, то дебаггером.

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

разбираться с настройками, однозначно. посмотрите в коде, как создается сокет и какие опции устанавливаются (можете сюда сбросить). ну сделаете вы мониторинг (что само по себе правильно и нужно), но как вы будете реагировать на проблему? имхо, костыль.

А там никак нельзя заставить клиента послать что-нибудь по этому соединению?

врядли

врядли

Тогда наверное ничего не поделаешь. Тушите свет.

все-таки главный вопрос - как избежать подобных случаев в будущем

Софт должен быть нормально написан. Либо Keep-Alive, либо проверка наличия связи на прикладном уровне. Других нормальных путей ИМХО нет.

супервайзер который будет проверять зависшие соединения

Супермегавайзер, думаю, доставит больше проблем, чем пользы.