Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Large numbers of errors in log #197

Open
jech opened this issue Jan 20, 2021 · 1 comment
Open

Large numbers of errors in log #197

jech opened this issue Jan 20, 2021 · 1 comment
Assignees

Comments

@jech
Copy link
Contributor

jech commented Jan 20, 2021

I've just run Galène against pion/turn instead of coturn. The server was moderately loaded, a few lectures with 20 or so students each. The log is riddled with messages that indicate problems between Galène and the TURN server — I haven't noticed any that indicate issues with communication with clients.

If my understanding of TURN is correct, some of the errors are not actual errors, but simply normal negotiation between the TURN client and server; in that case, the issue is that the default logging is too verbose. Others look worrying, and I'd appreciate a clarifiction.

Typical errors include:

turnc ERROR: 2021/01/19 16:34:56 fail to refresh permissions: CreatePermission error response (error 441: Wrong credentials: the realm value is incorrect

and

turn ERROR: 2021/01/19 16:35:01 error when handling datagram: failed to handle CreatePermission-request from 51.210.14.2:37880: no allocation found 51.210.14.2:37880:51.210.14.2:1194

and

turnc ERROR: 2021/01/19 16:35:09 fail to refresh permissions: all retransmissions failed for yoM0LWftNldeEfRt

and

turn ERROR: 2021/01/19 16:35:51 error when handling datagram: failed to handle Refresh-request from 51.210.14.2:37880: no allocation found 51.210.14.2:37880:51.210.14.2:1194
@jech
Copy link
Contributor Author

jech commented Jan 24, 2021

So I've looked at it in some more detail, and I see the following problems:

  • function readLoop unconditionally calls s.log.Errorf; it should call Warnf or Logf for errors that are likely to happen in normal behaviour;
  • the errors in internal/server are not exported, which means that you cannot easily decide on their type.

I can see two ways of solving the second issue. The simplest one would be to export the errors. The second one would be to add a method IsWarning(error) bool to the internal patckage that returns true if an error should be reported using Warnf.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants