No, if I stop the dovecot service. I am getting from haproxy the 'L4CON in 0ms' and when I start dovecot with the new printf in the bash script, the same error 'SOCKERR in 8ms'(not tried with the options haproxy, reuseport)
I am not sure what this haproxy=yes should do, but tcpdumps show that transmissions between curl requests and haproxy requests are handled differently. The people of haproxy say they use an OPTIONS request. I used this also with curl -X OPTIONS, but still the curl is returning ok, while haproxy keeps complaining. > Not sure where to report this as bug. Does it work if you change the > script to look like: > > printf 'HTTP/1.1 200 OK\r\nContent-Length: 0\r\n\r\n' > exit 0 > > > > > Should this be filed as a bug somewhere? > > > > > > > > > > I have been trying to get a simple health check in haproxy to work. > But > > > somehome the haproxy request is differently handled then a curl > request, > > > which generates a socket error in haproxy. > > > > > > The health script echos these lines, with this config[2] > > > > > > echo -ne "HTTP/1.1 200 OK\r\n" > > > echo -ne "Content-Length: 0\r\n" > > > echo -ne "\r\n" > > > exit 0 > > > > > > The curl request generates ok, haproxy generates socket error. The > > > haproxy=yes, reuseport=yes do not seem to resolve anything. If stop > > > dovecot and run "dovecot-health-check.sh | nc -l 192.168.10.46 5001" > > > then the haproxy check is ok. So I guess the script is ok. But what > is > > > dovecot then doing with it's output when haproxy is requesting it? > > > > > > > > > > > > [1] > > > https://discourse.haproxy.org/t/httpck-on-bash-script-results-in- > socket- > > > error/5647/16 > > > > > > [2] > > > service health-check { > > > executable = script -p /usr/local/sbin/dovecot-health-check.sh > > > inet_listener health-check { > > > port = 5001 > > > haproxy = no > > > reuse_port = no > > > } > > > }
