333.i2p

Посылка сигнала HUP приводит к неработоспособности серверных тоннелей в версии 2.38.

---

Починено в транке, т.е. в 2.40

Нет, не починил. Эта проблема по-прежнему наблюдается в Purple I2P 2.40.0.
На практике logrotate делает сетевые сервисы недоступными путём посылки сигнала HUP в рамках исполнения процедуры postrotate.

---

для logrotate надо слать USR1, а не HUP

Не суть важно, кто посылает HUP. Результат посылки остаётся неприемлемым - службы становятся недоступными

---

orignal, в версии 2.41 этот баг тоже присутствовал.
[s]Теперь баг пофишен, проверено мной. Версия 2.42.1.[/s]
Баг НЕ ПОЛНОСТЬЮ пофикшен!
Если во время HUP нет активных стримов у серверного туннеля, то он сохраняет работоспособность после HUP.
Если во время HUP были стримы у серверного туннеля, то они рвутся. Все новые стримы виснут с 500-1000 входящих и исходящих байт. На клиентской стороне просто нет ответа от сервера, соединение висит. На серверном роутере в логах куча "Streaming: Acceptor for incoming stream is not set". Вернуть серверный туннель в работоспоссобное состояние можно только закомментировав его в tunnels.conf, сделать HUP, раскомментировать, и еще раз HUP.

Эта проблема не распространяется на клиентские туннали. Если есть туннели с keys=имя_файла, то после HUP туннели продолжает работу, даже если были активные стримы. Они не рвутся. В отличие от ситуации с серверными туннелями.

Orignal, я постарался подробно расписать симпотомы проблемы. Надеюсь, это поможет в ее решении.

Last edited: Thu, 26 May 2022, 09:43pm от reportn462

reportn462 wrote:

Вернуть серверный туннель в работоспоссобное состояние можно только закомментировав его в tunnels.conf, сделать HUP, раскомментировать, и еще раз HUP.

У нас на 2.42.1 помогает вместо HUP просто рестарт сервиса. Но это хорошо, пока клиентов немного. А если будет с десяток пользователей отваливаться после добавления в access-лист очередного - это будет печально. :(