Just testing the message forwarding and reliability of plain TCP. Am aware of the un-reliability of that forwarding. See some missing messages after the rsyslog proper process restart on destination side. Configured simple TCP omfwd action with keepalive enabled. On receiving side imptcp input with keepalive enabled and global(inputs.timeout.shutdown="10000"). Unfortunately see rsyslog going down and closing listeners too fast - not accepting the timeout.shutdown value. After that the receiver does not wait for FIN,ACK from client side and just close the socket. The data being flushed from buffer on client side are responded with RST packet. Would expect the receiver to wait up to 10 seconds to let the clients flush the data. Have some remote sites with slow link - due to long distance - causing the socket sending queue being occupied most of the time.
Do not see this behavior as appropriate. Could anybody review the code? Is it bug or configuration issue? Found this code: https://github.com/rsyslog/rsyslog/blob/69f8e1d1f7fe62fd2c5f38a81d4102a9a62d1722/plugins/imptcp/imptcp.c#L2381 According to the documentation the two shutdown()s can be called before close(), but are not strictly required. Digging a little deeper discovered SO_LINGER is referenced, but with value of 0 https://github.com/rsyslog/rsyslog/blob/6f74f7e7b43eb32ab165c5975a0f7777cbbf0f21/runtime/nsd_ptcp.c#L359 which might be ok as with plain TCP there is no data transferred to client from the listener. And the SO_LINGER covers only flush buffered output (does not wait for incoming data) https://www.gnu.org/software/libc/manual/html_node/Opening-and-Closing-Files.html#Opening-and-Closing-Files Was not able to find the LINGERing on client side code. Traced socket handling in omfwd https://github.com/rsyslog/rsyslog/blob/1f8f621a97df6b1989e1aebd8cb15cd6a552fa9c/tools/omfwd.c was able to find the abort data in netstrm driver https://github.com/rsyslog/rsyslog/blob/6f74f7e7b43eb32ab165c5975a0f7777cbbf0f21/runtime/netstrm.c#L83 which seems related. Hopefully from the tcpdump that part of the code seems to be working as it is seen the client is trying to flush the data, all of which are responded with RST packet. Both sides are running Debian10 with Debian's rsyslog 8.1901.0-1. Any help to sort this out is appreciated. Peter _______________________________________________ rsyslog mailing list https://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
