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.
