timeout flooding in murmur logs about mumble

[Kissaki]

Can you check on the connection-IDs, whether that's people that were successfully connected to mumble and then exited?
Or maybe it's from people who get disconnected otherwise / completely.

Do you or other people use any bots or scripts that connect to your Mumble server?

[Kissaki]

• status: open --> awaiting-reply
• Version: --> 1.2.3
• Targeted Release: 1.2.3 --> unspecified

No bots or scripts are being used on my server. I'm unable to check connection-IDs currently, as the flooding has wiped away all entries concerning connections. What I can tell you is that the logs are still being flooded and no one is using the server at the moment.

[Kissaki]

Are you checking the logs via a web interface?
You should still be able to check the logs written to disk. They don’t get pruned AFAIK.

What I’d check next then is if your Mumble server actually gets incoming connections (incomplete connect requests).
Maybe you can netstat that, or otherwise network-log?

Here is a snippet showing everything leading up to the last flooding incident. I've partially masked the IPs but everything else is untouched.

The following attachments were added on the original comment:

• https://sourceforge.net/p/mumble/bugs/_discuss/thread/064d7e4a/e2a3/attachment/murmur_log_%20snippet.txt

[Kissaki]

So a normal connection looks like

 <W>2013-04-19 21:10:14.761 1 => <59:(-1)> New connection: 0.0.136.205:51041
<W>2013-04-19 21:10:15.214 1 => <59:(-1)> Client version 1.2.3 (Win: 1.2.3)
<W>2013-04-19 21:10:15.433 1 => <59:Blackdragon(108)> Authenticated

All those timeouts seem to not announce their client version and then either close or time out.
Logging that stuff is not wrong or arguable really. If (some kind of) client initiates a connection it should be logged- and also what follows.

Okay, but that is only a tiny snippet of the log file.

The timeouts you see at the bottom repeat for 57,573 lines with the same connection IDs (in this case 68, 72, 78, 84, and 86) over and over again until I finally noticed it and restarted the server. These repeating entries keep flooding even if no one has connected to the server for days.

[Kissaki]

Mh, interesting that a restart prevents further such loggings. Is the restart instantly? ( < 2s?)

I guess one should at least check the code, if it’s an issue of connection handling or wrong logging …

Oh I see, for one connection it logs a timeout multiple times.
Then a restart fixing it makes sense.
I wonder where the empty reason -1 connection close comes from though.

I restart it by choosing "Quit Murmur" from the tray icon, then launching it again from a desktop shortcut. Can't say for certain how long that takes, but 2-5 seconds seems like a reasonable guess.

[Kissaki]

• status: awaiting-reply --> accepted

[Krzmbrzl]

Is this (still) reproducible in v1.3?

[no-response]

This issue has been automatically closed because there has been no response to our request for more information.
With only the information that is currently in the issue, we don't have enough information to take action.

Please reach out if you have or find the answers we need so that we can investigate further (or if you feel like this issue shouldn't be closed for another reason).