Race condition with local IRCd #751
Assignees
adam (Adam Wojcieszonek)
Clear assignees
adam (Adam Wojcieszonek)
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: adam/znc#751
Reference in new issue
Block a user
When running an IRCd on the same machine as ZNC, you can create a race condition when sending a large amount of commands in succession.
For my example when I connect I identify to my networks services and oper up and join 10 or so channels with the perform module. Then any command I execute after that is in-fact the response of the last x command. So if I whois I'll get the response from some command executed during the perform, then I'll message a channel and my client will get the response from the whois.
Flood protection is off, that made it worse from what I can remember.
I worked around this by slowing down my perform and I'm able to hold a connection, however if I execute a large number of commands in succession later on after being connected for days/weeks I can recreate the same problem.
Which evidently results in znc timing out as it never replies to a ping/pong request.
Show logs of
znc -D(replace all passwords with xxx), that will make the problem much easier to understand. Also what version do you use?Why do you use perform module to join channels instead of letting ZNC do it?
IRC protocol doesn't support distinguishing what response was for which command. The good news is http://ircv3.net/specs/extensions/labeled-response.html will help, when implemented.
What do you mean?
Why it doesn't?
@DarthGandalf
Here you go, because znc sees the last command or something, regarding the ping. Slowing down perform I put some sleeps in. ZNC does join them sorry but I cut them out on this one just opered up and ID to services still creates the problem.
How did you put sleeps to perform module? It doesn't support that.
I don't see PING in your log at all. There's nothing to reply PONG to.
By looking at timestamps, IRCd didn't reply to one of WHOISes immediately, but waited till the next one. ZNC can't do anything about when IRCd replies.
As for matching between requests and responses, the
labeled-responseextension will help in this case, but it needs to be implemented by IRCd, by ZNC and by your client.PS. I edited your log to be actually readable, between triple-`
I added that to the .so file myself but restored it to default for this test.
No pings because I didn't leave it running long enough
It took two /whois' for znc to read the right reply from the IRCd it was still reading mode replies for two of them, then down the bottom I /whois'd another nick and it was giving me replies from the previous nick I whois'd.
I don't believe this is an issue with the IRCd, ZNC just has a race condition somewhere and it's not reading replies sockets entirely. If I turn perform off and wait like 5 seconds after connecting and run each command manually it's all good. But then if I run a lot of commands in succession at any point after that weeks or months after connecting it breaks again.
Look at 05:17:39 in the log above. ZNC correctly forwarded WHOIS and correctly forwarded the responses it got. If it didn't receive any response from server, it can't forward anything.
Do you expect it to invent a response out of nowhere?
Which proves that it's not because of perform, but because of running too many commands in a row.
Here's an experiment: connect client to server directly, without ZNC, and run many WHOIS commands one after each other. Will it show the same behavior?
Well that's interesting it appears to be a race condition in inspircd v2, I was able to recreate the issue with irrsi. That's not good! Sorry for wasting your time on this you can close this issue.
No problem, you could close it yourself.
If you open a bug against inspircd, feel free to mention this thread there, so that github would add links in both directions.