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 0The 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 } }