dovecot - Nov 2021 - health check passthrough not 100% in combination with haproxy

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

Aki
> On 19/10/2021 23:29 Marc <marc at f1-outsourcing.eu> wrote:
> 
>  
> 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
> >  }
> > }

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

I noticed that your script didn't work for me, for some reason I got

-ne HTTP/1.1 200 OK

-ne Content-Length: 0

-ne 

which of course does not make sense... can you try if this works? I'm
guessing your script probably looks pretty much like this already...

#!/bin/bash
timeout=10
trap "exit 0" QUIT
{
        sleep $timeout
        kill -3 $$ 2>/dev/null
} &
read -r input
exit_code=$?
if [ ${exit_code} -eq 0 ]; then
    echo -n -e "HTTP/1.1 200 OK\r\n"
    echo -n -e "Content-Length: 0\r\n"
    echo -n -e "\r\n"
fi
exit 0
> On 20/10/2021 11:55 Marc <marc at f1-outsourcing.eu> wrote:
> 
>  
> 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
> > > >  }
> > > > }