Long time between time-out and reconnection of znc server IP change #218

New Issue

2026-10-05T04:05:39+02:00

adam commented

2026-10-05 04:05:39 +02:00

My ZNC server (raspberry pi, znc 1.0) is connected to a DSL router. From time to time, the DSL synchronization fails and the router goes through the synchroniazation steps and gets a new IP from the ISP.
This results in a long delay between the time the ZNC server times out and reconnects.
An example from #exult on freenode:
[22:54:40] <-- Dominus has left IRC (Read error: Operation timed out)
[23:02:20] --> Dominus has joined #exult

According to the router logs, the new IP was given at 22:53:45.

I thought this to be an issue with the Raspberry but when I had ZNC running on my Mac Mini the delay was about the same time.

My ZNC server (raspberry pi, znc 1.0) is connected to a DSL router. From time to time, the DSL synchronization fails and the router goes through the synchroniazation steps and gets a new IP from the ISP. This results in a long delay between the time the ZNC server times out and reconnects. An example from #exult on freenode: [22:54:40] <-- Dominus has left IRC (Read error: Operation timed out) [23:02:20] --> Dominus has joined #exult According to the router logs, the new IP was given at 22:53:45. I thought this to be an issue with the Raspberry but when I had ZNC running on my Mac Mini the delay was about the same time.

adam closed this issue

2026-10-05 04:05:39 +02:00

adam commented

2026-10-05 04:05:40 +02:00

From looking at the code, the current implementation is:

A connection to an IRCd times out after nothing was read for 540 seconds (This is set up by the SetTimoeut() call in the code handling raw 001)
After at most 300 seconds without reading anything, znc starts sending PINGs to the IRCd (this might give the system's TCP stack a chance to notice that the connection is dead) (also, PONGs are just ignored, so the normal timeout logic from above handles missing PONGs)

So in your case the current connection was dead at 22:53:45 and the reconnect finished at something like 23:02:20. That's a total of 515 seconds which is way below the worst possible value.

(All of this ignores the time that it takes for the reconnect, which can take quite a while, too)

So at least the behavior seen matches what I would expect.

From looking at the code, the current implementation is: - A connection to an IRCd times out after nothing was read for 540 seconds (This is set up by the SetTimoeut() call in the code handling raw 001) - After at most 300 seconds without reading anything, znc starts sending PINGs to the IRCd (this might give the system's TCP stack a chance to notice that the connection is dead) (also, PONGs are just ignored, so the normal timeout logic from above handles missing PONGs) So in your case the current connection was dead at 22:53:45 and the reconnect finished at something like 23:02:20. That's a total of 515 seconds which is way below the worst possible value. (All of this ignores the time that it takes for the reconnect, which can take quite a while, too) So at least the behavior seen matches what I would expect.

adam commented

2026-10-05 04:05:41 +02:00

Thanks for stepping through the code for me.

So, I guess I want to log a feature request to set those above manually in the conf file (and web interface eventually).

It is rather annoying when you write stuff in a client connected to znc and it doesn't get send because the znc is actually not connected at that moment :(
And the client doesn't know that of course since its connection to the znc server is still fine (at least when I connect through my local net and not via the dyndns).

Thanks for stepping through the code for me. So, I guess I want to log a feature request to set those above manually in the conf file (and web interface eventually). It is rather annoying when you write stuff in a client connected to znc and it doesn't get send because the znc is actually not connected at that moment :( And the client doesn't know that of course since its connection to the znc server is still fine (at least when I connect through my local net and not via the dyndns).

adam commented

2026-10-05 04:05:41 +02:00

Same "problem" here, too. Did you add the feature request?

Same "problem" here, too. Did you add the feature request?

adam commented

2026-10-05 04:05:42 +02:00

Duplicate of #979

Duplicate of #979

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/znc#218