Hi Elastic team,
I’m trying to better understand how client_inactivity_timeout works in Logstash, specifically in relation to how it closes idle TCP connections.
Context:
We have Winlogbeat agents sending logs over TCP to Logstash. Winlogbeat sends TCP keep-alives every ~15 seconds, and these are acknowledged by the OS on the Logstash side (confirmed via Wireshark). However, when no log events are sent for the duration of client_inactivity_timeout, Logstash closes the connection by sending a TCP RST (reset), not a FIN.
My question:
Is it expected behavior for Logstash to terminate idle TCP connections with a RST rather than FIN/ACK?
From a networking standpoint, I would expect FIN/ACK for a normal connection shutdown. A RST usually signals an error, and this has consequences:
- On the Winlogbeat side, it’s logged as an error:"An existing connection was forcibly closed by the remote host."
- This makes it appear as if something went wrong, even though it’s just an expected timeout on the Logstash side.
Suggestion:
Using FIN/ACK would make this a clean and unambiguous connection close. It would also reduce confusion during debugging, especially since the agents treat RST as a sign of failure.
Thanks for any clarification — is this behavior intentional, and if so, could there be an option in the future to allow graceful termination?