Hello,
Issue:
It appears that there is a bug in v3.0+ where the TCP client does not correctly dispose of its connection. This results in the background thread crashing silently as it tries to bind to an already bound port.
Details:
We have a site set up using IIS, and after ~20-30 minutes of inactivity (no requests/logs/etc) all logging stops due to the Graylog sink trying to reconnect on a TCP port that was already bound on the initial startup. This exception was silent and did not even show in the Windows Event Viewer, nor was it causing the application to stop functioning, however all logging (all Serilog sinks) stopped working. It would seem as if this was a detached background thread, but I'm not entirely familiar with how Serilog handles its providers/sinks. I have attached some information below, we had to use DebugDiag to catch the exception.
The offending line appears to be line 65 in the TcpTransportClient class:
|
await _client.ConnectAsync(_address, port).ConfigureAwait(false); |
Workaround:
There are a couple "workarounds" for these but these do not actually fix the core issue:
- Use the UDP transport type to bypass the TCP Client
- Rolling back to v2.3.0 resolves the issue as the TCP connection is properly disposed.
- Recycling the app pool also resolves the issue, but it will just reoccur after a period of inactivity.


Sink config:
"Serilog": {
"Using": [ "Serilog.Sinks.Graylog" ],
"MinimumLevel": {
"Default": "Debug",
"Override": {
"Microsoft": "Information",
"Microsoft.Hosting.Lifetime": "Information"
}
},
"WriteTo": [
{
"Name": "Graylog",
"Args": {
"hostnameOrAddress": "[omitted]",
"port": "12201",
"transportType": "Tcp"
}
}
]
}
App pool config:

Hello,
Issue:
It appears that there is a bug in v3.0+ where the TCP client does not correctly dispose of its connection. This results in the background thread crashing silently as it tries to bind to an already bound port.
Details:
We have a site set up using IIS, and after ~20-30 minutes of inactivity (no requests/logs/etc) all logging stops due to the Graylog sink trying to reconnect on a TCP port that was already bound on the initial startup. This exception was silent and did not even show in the Windows Event Viewer, nor was it causing the application to stop functioning, however all logging (all Serilog sinks) stopped working. It would seem as if this was a detached background thread, but I'm not entirely familiar with how Serilog handles its providers/sinks. I have attached some information below, we had to use
DebugDiagto catch the exception.The offending line appears to be line 65 in the
TcpTransportClientclass:serilog-sinks-graylog/src/Serilog.Sinks.Graylog.Core/Transport/Tcp/TcpTransportClient.cs
Line 65 in 64532fa
Workaround:
There are a couple "workarounds" for these but these do not actually fix the core issue:
Sink config:
App pool config:
