Как подписаться на событие «появился слушающий tcp-сокет»?

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

Это больше для случаев перезапуска редиса и прочего подобного форс-мажора.

А протокол, протокол то там какой?

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

Мне нужно сделать переподключение на сокет когда redis поднимется. Это либо поллинг с заданным интервалом, либо реакция на событие. Хотелось бы последнее.

В моем вопросе часть ответа.

Протокол, гм, чего?

Хм... Или это предложение следить за unix-сокетом? Можно, но сильно ограничивает функциональные возможности...

Протокол, по которому идет обмен данными. Полагаю, что-то там работает поверх TCP. Вот в спеках на эту штуку ищи есть ли что-то про реконнект или типа кип-алайв.

Скульптурная аватара...

У ТСа тоже.

Омг. Недодевелопер пытается давать советы недоадмину в системщине. Это так мило.

Интересно, когда до ТС дойдет, что его Y не поможет решить X.

Омг. Кто-то, вместо того чтобы показать уровень своих знаний и тем подтвердить свою авторитетность, объяснить обоим как делать надо, пояснив ссылками, примерами, пытается строить из себя умного. Это так мило.

Так ты умный, но просто троллишь или за трололо скрывается лишь притворство умным?

объяснить обоим как делать надо

А чего объяснять, автор, вполне четко обозначил проблему, ты лезешь с протоколом, хотя соединения нет. Задача не как поддержать соединение, а что делать когда оно порвалось. Это сеть и она будет рваться. Тебе хоть кол на голове чеши.

А ТС мне тупо не нравится, чтобы разжевывать — недоучка с апломбом.

А протокол может в себя включать возможности, что можно использовать если сеть порвалась. Как пример — хттп, 206 партиал контент, докачка файла. Да и сам тисипи — подтверждение о получении приходит отправителю. Может в его (ТСа) протоколе есть хоть что-то, что поможет. Мне показалось не лишним посоветовать заглянуть в спеки.

Анонимус - типичное желчное рашко-срано-быдло, не стоит обращать на такое внимание.

Относительно протокола - нет, протокол red is, в отличие от протокола, http, рассчитан на поддержание соединения, а не на множество соединений с поддержкой состояния внешними по отношению к протоколу средствами.

Вообще конечно сама идея броадкастинга - она же на то и рассчитана, чтобы отправитель ничем не был обязан получателям/подписчикам. Не «услышал» подписчик - его проблема. Можно хитроумными способами добиться того, чтобы подписчиков мог всё-таки добрать пропущенное (сохраняя срез за последние N минут), но это несколько дурацкая затея.

Да, как я понимаю, inotify для виртуальных ФС типа /proc неприменим.

Кстати, задача неплохо решается, если всё дело только в перезапуске сервиса (через dbus можно «послушать» сообщение о подъёме сервиса), но, опять же, это слишком частный случай.

И хотелось бы просто поставить обработчик «когда поднимется обратно

Вот тут-то и собака порылась...кто кроме как ты может поставить обработчик? Пусти его в отдельном треде и будет тебе счастье да семафор проверяй в мейн лупе :).

если редис сервер упал ? чекать когда он поднимется и что то сделать ?
очевидно писать либо простенький скрипт который долбится на порт редиса, но с учетом ТСП такие чеки будут затратные, если редис упал и порта нет, то коннект к порту которого нет будет висеть долго
самый простой способ, если скрипт который с каким то интервалом смотрит по netstat или lsof есть ли редис с процессах со своим портом
как к примеру https://superuser.com/questions/565991/how-to-determine-the-socket-connection...

Может, оно и не мега-критично, но если бы и подписчики, и отправители восстанавливали соединение ASAP - такой фигни бы не было.

Было бы всё равно, просто с меньшей вероятностью.

Правильней сделать протокол доставки сообщений стойким к разрывам соединений, т.е. сохранять где-то сообщения для отключенных подписчиков, чтобы при их подключении сбрасывать им всё, что накопилось за их отсутствие. Не знаю, умеет ли redis такое.

В том-то и дело, что у меня уже есть реализация «накопления» очереди недоставленных сообщений и публикация их после подключения - но при этом сами подписчики могут восстановить связь не сразу, и тогда кто-то получает неотправленное за время аварии, а кто-то - получает не всё или вообще не успевает получить эту порцию. Тут дело в самой логике «редис-вещания»: в общем-то ни одна радиостанция же не можем повторять сообщения что-то пропустившим отдельным слушателям. Похоже, единственный выход - после разрыва соединения просто долбиться subscriber'ами почаще, чтобы у них было больше шансов получить всё или хотя бы потерять минимум сообщений.

Да, всё это завязано ещё с тем, что моя реализация «редис-вещателя» старается сохранять последовательность публикуемых сообщений во что бы то ни стало, поэтому не может пропихивать неопубликованное за время простоя частями с каким-то интервалом, чтобы уж точно все подписчики «проснулись»...

Создание сокета - событие уровня ядра всё-таки, почему же я могу ставить inotify-обработчики на файлы, а на сокеты не могу?...

Анонимус - типичное желчное рашко-срано-быдло, не стоит обращать на такое внимание.

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

Но остаётся только долбить ОС

ставят таймер 1 сек (именно поэтому хром/офис/и все все все так тормозит ибо сокеты падают вкладки закрываются менюшки на событиях и на перерисовку/обновление(после потери связи) стоит таймер 1 сек чтоб не долбить)

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

ну можете еще поизучать NETLINK_INET_DIAG http://kristrev.github.io/2013/07/26/passive-monitoring-of-sockets-on-linux, но это тоже самое что я советовал выше про lsof

Так вроде системд должен следить за сервисами и оповещать тоже может, когда сервис упал и когда поднялся, нужно смотреть доки типа системд+питон/ноду, и из них отправлять оповещения нужному потребителю.

Потому что СОЗДАНИЕ сокета(читай файл дескриптора) почти никак (для юзер спейса) не связано с событиями в кернел спейсе и сетевом стеке. Хотя, я так думаю, можешь получить/прочитать через нетлинк нужную инфу.