On Thu, 8 Oct 2009, Rainer Gerhards wrote: >> [email protected]] On Behalf Of [email protected] >> >> On Wed, 7 Oct 2009, Jonathan Bond-Caron wrote: >> >>> The client 'sends the message over tcp' and actually empties the >> queue! >>> >>> Is this expected behavior? rsyslogd was shutdown 'cleanly' on the >> server. >>> Shouldn't it force the client to close the TCP connection? >>> >>> >>> >>> Using netstat, the two servers are : >>> >>> >>> >>> Proto Recv-Q Send-Q Local Address Foreign Address >> (state) >>> >>> tcp4 0 0 client.10514 server..60726 FIN_WAIT_2 >>> >>> >>> >>> Proto Recv-Q Send-Q Local Address Foreign Address >>> State >>> >>> tcp 1 36 server:60726 client:10514 >> CLOSE_WAIT >>> >>> >>> >>> Have I misunderstood something? I've read Rainer's blog and issues >> with TCP >>> "unreliability" / case of a power failure but don't think this >> related >> >> I think it's the same problem, one side thinks the connection is >> closed, >> the other doesn't and so the one that doesn't happily sends the data >> out. >> >> try reconfiguring to use relp and things should work as expected. >> >> >> now, I don't know why the close isn't getting through from the one >> system >> to the other rapidly. is there any sort of firewall in between them? > > The close may get through. It is a (kind of) race condition, inside the tcp > stack. Assume the following happens (System S being the server, system C > being the client): > > S : closes connection, sends close info > C1: rsyslog writes data (not yet sent, but acknowledged by tcp stack) > C2: receives close request > C3: discards data > > The race is in C1/C2. In this order, data is lost. If C2 happens before C1, > no data is lost. No chance to solve that with plain tcp without app-level > acks.
but that window should be very short, for it to last long enough to show up in the netstat commands sounds odd to me. David Lang _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
