What's the purpose of inputs.timeout.shutdown then. Thought it should cover this scenario in a way that the clients will have enough time to send the data from buffers before closing the socket. Shouldn't the listener wait the time defined in inputs.timeout.shutdown for client's response with FIN,ACK? Would expect that.
Peter On Wed, Apr 29, 2020 at 1:03 PM Rainer Gerhards <[email protected]> wrote: > no, the receiver shuts down as soon as possible. This is intended. > Otherwise you get even longer shutdown times. > > Rainer > > El mié., 29 abr. 2020 a las 13:00, Peter Viskup via rsyslog > (<[email protected]>) escribió: > > > > 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. > _______________________________________________ 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.
