[rsyslog] Queue System

[david at lang.hm]

On Thu, 8 Oct 2009, Rainer Gerhards wrote:

>> bounces at lists.adiscon.com] On Behalf Of david at lang.hm
>>
>> 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