Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#981 timeout flooding in murmur logs

unspecified
accepted
nobody
None
1.2.3
5
7 days ago
2013-04-21
eGaTS
No

Server:
Murmur 1.2.3
WinXP Pro SP3
3GHz Pentium 4 with 2GB RAM

Constant flooding like this in my logs:

<W>2013-04-21 01:45:09.292 1 => <68:(-1)> Timeout
<W>2013-04-21 01:45:09.371 1 => <86:(-1)> Timeout
<W>2013-04-21 01:45:09.449 1 => <72:(-1)> Timeout
<W>2013-04-21 01:45:09.527 1 => <78:(-1)> Timeout
<W>2013-04-21 01:45:09.589 1 => <84:(-1)> Timeout
<W>2013-04-21 01:45:24.824 1 => <68:(-1)> Timeout
<W>2013-04-21 01:45:24.871 1 => <86:(-1)> Timeout
<W>2013-04-21 01:45:24.917 1 => <72:(-1)> Timeout
<W>2013-04-21 01:45:24.980 1 => <78:(-1)> Timeout
<W>2013-04-21 01:45:25.042 1 => <84:(-1)> Timeout
<W>2013-04-21 01:45:40.308 1 => <68:(-1)> Timeout
<W>2013-04-21 01:45:40.386 1 => <86:(-1)> Timeout
<W>2013-04-21 01:45:40.464 1 => <72:(-1)> Timeout
<W>2013-04-21 01:45:40.511 1 => <78:(-1)> Timeout
<W>2013-04-21 01:45:40.574 1 => <84:(-1)> Timeout
<W>2013-04-21 01:45:55.792 1 => <68:(-1)> Timeout
<W>2013-04-21 01:45:55.855 1 => <86:(-1)> Timeout
<W>2013-04-21 01:45:55.917 1 => <72:(-1)> Timeout
<W>2013-04-21 01:45:55.980 1 => <78:(-1)> Timeout
<W>2013-04-21 01:45:56.042 1 => <84:(-1)> Timeout

I saw this posted as a bug and closed 5 years ago, but saw no reasonable solution in the thread. I've been experiencing this problem for at least a year-- just never got around to reporting it.

We have no connection issues. Things seem okay except for the flooding.

Restarting the server stops the flooding, but when left unattended the logs grow unnecessarily huge. Has this issue been addressed in 1.2.4-RC? I'm hesitant to upgrade at this point as the server is essential for raiding on a weekly basis.

Related

Bugs: #111

Discussion

  • Kissaki
    Kissaki
    2013-04-22

    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
    Kissaki
    2013-04-22

    • status: open --> awaiting-reply
    • Version: --> 1.2.3
    • Targeted Release: 1.2.3 --> unspecified
     
  • eGaTS
    eGaTS
    2013-04-22

    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
    Kissaki
    2013-04-22

    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?

     
  • eGaTS
    eGaTS
    2013-04-22

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

     
    • Kissaki
      Kissaki
      2013-04-22

      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.

       
  • eGaTS
    eGaTS
    2013-04-22

    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
      Kissaki
      2013-04-23

      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.

       
  • eGaTS
    eGaTS
    2013-04-24

    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
    Kissaki
    2013-05-11

    • status: awaiting-reply --> accepted