I setup a duplicate config on my local workstation (our production one is quite large and not suitable for sharing in its entirety). Interestingly I can't get an 'SC--' with a <NOSRV> when doing tcp-request connection reject.
I'll dig a bit further. Is there any other scenario that might cause an SC-- termination state with <NOSRV>? Thanks! Jason On Thu, Mar 26, 2015 at 5:02 PM, Cyril Bonté <[email protected]> wrote: > 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é
