ZNC fails to reconnect users after misc types of disconnects #379
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#379
Reference in new issue
Block a user
I'm running ZNC 1.5-git-257-0908023 (latest as of this post, I believe), and after a day or so of ZNC running, I notice that if a user disconnects (may it be with controlpanel, *status disconnect, IRC server pinging out, or even ZNC losing connection to IRC), the user will not reconnect to the server.
Not just a single server, but any server, any user, etc. I have tried running ZNC in debug mode (foreground), and I do not see any errors of any kind, so I'm unsure of what's causing this. ZNC also doesn't notify users that there was a failed attempt, or anything of the sort. No messages are sent after "Connecting" or whatever.
Each user is using a bindhost (however I'm sure this isn't affecting it because a reboot with the same hostnames causes them to connect), and ZNC is being run under supervisord.
Is there any way I can further diagnose this issue?
You might want to try using
straceon it to see what ZNC is actually doing, an easy way to do so is usinghtopand using the keysover the process.I'm not sure exactly what I should be looking for inside strace. I'm noticing three processes of znc (they may be childs/etc), each one outputs a little different data. and lots of it.
Oddly enough, as soon as I strace, they are reconnecting. Is that odd?
After days of not reconnecting, they reconnect. I think last time I was suggested to use strace, it did the same thing before but I wasn't sure if strace did it or what, now I'm really confused.
With
*status disconnectand*controlpanelthis is the expected behavior. If user explicitly told ZNC that it should be disconnected, why would it connect?If IRC server went down, and connection got lost, probably the server was simply down all the time?
It doesn't connect at all?
It looks like this could be caused by identfile module; do you have it loaded?
@DarthGandalf I didn't simply do *disconnect... I did *connect afterwards. And it didn't actually connect.
"If IRC server went down, and connection got lost, probably the server was simply down all the time?"
Clearly not, if people are connected to that server, and all servers seem to be up within the main server.
And yes, it doesn't connect at all, doesn't show errors in debug, and doesn't output ANYTHING to the user. It seems it's half-ass fixable by doing what chauffer stated. I'm not even sure HOW that fixes it, or what it does, either. but running "strace" inside htop, causes all users that were previously disconnected, to reconnect. Again I don't understand the connection between the two, but after I do that, it fixes it until I reboot znc.
On another note, I would say identfile.. However there are many things that prove identfile to be working. All users connect and successfully use the identfile when connecting to the server (and that is seen due to no ~ on each users ident). The identserver never needs to be rebooted (although, yes I've tried that), so I believe it's something directly related to either ZNC, or possibly how ZNC is run under Supervisord. (But, again, I ran supervisord on my old server with the same setup and no issues, so I'm not sure if supervisord could be the cause)
Seeming how strace is just related to determining what a process is doing/watching the process, I don't see how it would directly do anything to the process.
So identfile is loaded, right? What does
/msg *identfile showsay during such non-connect?This module creates artificial bottleneck; it make users to connect one at a time. Next user won't connect until "current" one is connected.
showshows which user is considered "current" by identfile module. If there is one user/network connecting there, need to investigate why that one doesn't connect.Also you can try to unload identfile. And to try without supervisord, as you suspect it; just run znc directly with the right arguments under the right system user.
Why strace "fixes" it... This could be some weird race somewhere, and strace has slight performance hit on process, so probably that's enough to not trigger that race anymore.
This did in fact reoccur again, I did "/msg *identfile show" and noticed that it was continously not changing.. It was stuck on a user that has been inactive for a long time, so I deleted that account and ZNC crashed (or something, rebooted). All of a sudden everyone started connecting again, after that, and I haven't had an issue since. I'm looking more into the problem but it seems it's no longer reoccuring, and I didn't notice anything odd about the users settings, or anything weird when I looked over the config for that user. I guess if I find out more I'll let you know.