________________________________
> Date: Mon, 13 Oct 2014 18:21:25 +0200
> Subject: Sessions idle not closed by HAProxy
> From: [email protected]
> To: [email protected]
>
> Hello,
>
> I'm having trouble with some connections active for hours on HAProxy
> (1.5.2) but not doing anything.
> Timeouts are defined like this :
> timeout connect 5s
> timeout http-keep-alive 5s
> timeout http-request 10s
> timeout queue 30s
> timeout client 25s
> timeout server 1m
> timeout tarpit 1m
>
> If I look at a specific connection and tcpdump it, I see absolutely no
> trafic, so I was expecting HAProxy to close the connection when either
> 'timeout client' or 'timeout tarpit' is elapsed.
>
> "show sess" on such connection shows output like this :
>
> 0x2046920: [13/Oct/2014:15:23:20.164269] id=1125543 proto=tcpv4
> source=XXX:26337
> flags=0x80, conn_retries=0, srv_conn=(nil), pend_pos=(nil)
> frontend=XXX:80 (id=129 mode=http), listener=? (id=1) addr=XXX:80
> backend=XXX:80 (id=129 mode=http)
> server=<none> (id=0)
> task=0x2046c90 (state=0x08 nice=0 calls=7 exp=<NEVER> age=2h32m)
> txn=0x2046968 flags=0x28000010 meth=4 status=-1
> req.st<http://req.st>=MSG_BODY rsp.st<http://rsp.st>=MSG_RPBEFORE
> si[0]=0x2046b70 (state=EST flags=0x0c endp0=CONN:0x3c8deb0
> exp=<NEVER>, et=0x000)
> si[1]=0x2046ba8 (state=INI flags=0x00 endp1=NONE:(nil) exp=<NEVER>,
> et=0x000)
> co0=0x3c8deb0 ctrl=tcpv4 xprt=RAW data=STRM target=LISTENER:0x1334dc0
> flags=0x8020b300 fd=921 fd.state=22 fd.cache=0 updt=0
> req=0x245bcf0 (f=0x000000 an=0x200 pipe=0 tofwd=0 total=8550)
> an_exp=<NEVER> rex=<NEVER> wex=<NEVER>
> buf=0x292e590 data=0x292e5a4 o=0 p=0 req.next=334 i=8192 size=16384
> res=0x245bc90 (f=0x000000 an=0x0 pipe=0 tofwd=0 total=0)
> an_exp=<NEVER> rex=<NEVER> wex=<NEVER>
> buf=0x292a560 data=0x292a574 o=0 p=0 rsp.next=0 i=0 size=16384
>
>
> I mentioned tarpit because there is a high chance connection was tarpitted.
>
> In the output above, I can see task state 0x08. Where could I find what
> this is ? If I take a look at stream_interface.h, there are several
> values mapped to 0x08...
>
> Any help would be appreciated :)
Upgrade to the latest stable release, this has already been fixed.
Regards,
Lukas
