I am getting these
synapse~ synapse/synapse1 0/0/0/-1/5 502 214 - - SHNN 3/1/0/0/0 0/0 “GET / HTTP/1.1”
https _recir_synapse/loopback-for-tls 5/0/1839 2339 SD 2/1/0/0/0 0/0
I saw some posts and tried to remove “mode http” and added tune.http.maxhdr, but does not seem to help.
For the SH error code we document:
SH The server aborted before sending its full HTTP response headers, or
it crashed while processing the request. Since a server aborting at
this moment is very rare, it would be wise to inspect its logs to
control whether it crashed and why. The logged request may indicate a
small set of faulty requests, demonstrating bugs in the application.
Sometimes this might also be caused by an IDS killing the connection
between haproxy and the server.
For the SD error code we document:
SD The connection to the server died with an error during the data
transfer. This usually means that haproxy has received an RST from
the server or an ICMP message from an intermediate equipment while
exchanging data with the server. This can be caused by a server crash
or by a network issue on an intermediate equipment.
So there is probably nothing on haproxy that can be done. If you don’t believe your backend server is the one causing the issue, capture the traffic between haproxy and the backend and analyze it.
Hmmm, I am able to connect to the backend server with lynx.
Currently I moved to this message
0/0/0/-1/2 502 214 - - SH-- 2/1/0/0/0 0/0
I did not say haproxy is unable to connect. The data transfer is aborted in the middle, as per the above doc explanation.
I was missing the ssl keyword in servers, pffff.
When I was testing this, I noticed that my haproxy task all of sudden was on another host. I am not really sure why this was happening can be a configuration issue but could also task ‘crash’. I still have sort of a testing container environment.
If it was a task crash it could be related to my dns issues or the fact that the backend server was tested http while it should have been https. Do you want me to investigate this? Or is this known?
What do you mean by task exactly?
If you have a reproducible haproxy crash, or a coredump and can provide the backtraces, please open a github issue with (all) that data.
A high-level description about a unreproducible crash without backtrace or coredump is probably not going to lead to a fix any time soon.
In mesos container applications are called tasks.
I will try and grab some more info. I had this haproxy running for two days, and the only thing I was now working on was adding a backend with srv lookups and ssl which had the wrong certificate. When I restarted this backend server I noticed haproxy moved to a different host.