Hi Jason, Le 27/03/2015 01:14, Jason Harvey a écrit :
Hello!I recently ran into a case where I was hunting down the cause of the termination of a request looking like the following (IPs changed to protect the innocent and/or guilty): Mar 26 23:01:43 localhost haproxy[17207]: 1.2.3.4:19036 [26/Mar/2015:23:01:43.477] http-in http-in/<NOSRV> -1/-1/-1/-1/0 503 1130 - - SC-- 601/38/0/0/0 0/0 {||3.4.5.6||||||} {||||||||||||||||} "GET / HTTP/1.1" What first caught my eye was the 'SC' termination state, which I believed suggested that a backend server had rejected this request. However as you can see from above, not only is there no backend, it is a <NOSRV>. After fumbling around for a bit I realized that this request matched a 'tcp-request connection reject' in the frontend.
Weird, because 'tcp-request connection reject' is not supposed to log anything. It's designed to silently reject the incoming connection.
Can you share your configuration (don't forget to remove sensitive data) and the output of "haproxy -vv" ?
This surprised me, as I didn't anticipate the resulting termination_state. The docs specifically say that an 'S' means that the session was aborted "by the server", when in fact no server was involved, as evidenced by the <NOSRV> line.
At this point, the configuration should help to see what happens.
If this is working as intended, would it be reasonable to adjust the documentation of the flags to account for such a case? I'm also trying to determine how to appropriately monitor these cases. If a flag says 'S', up until now I've believed that to have only been possibly caused by a server, and as such my monitoring is designed with this assumption. Now I realize that if it is 'S', I guess I need to check the server info in the log to determine if it was truly a server's fault, or it was nuked by haproxy. Any thoughts or suggestions? If this is *not* working as intended, might I suggest a special termination flag, like what we get with 'tarpit'? Thanks! Jason Harvey
-- Cyril Bonté
