Error message for missing haproxy binary is confusing

[Xiol]

Hi,

I had a typo in my systemd unit for the data plane service, pointing the --haproxy-bin option to /usr/bin/haproxy instead of /usr/sbin/haproxy. This resulted in useless error messages from any endpoints that wanted to use the binary, e.g.:

% curl -X POST --user dataplaneapi:password \                                                       
  -H "Content-Type: application/json" \
  -d '{"name": "test_frontend", "default_backend": "be_web", "mode": "http", "maxconn": 2000}' \
  "http://localhost:5555/v1/services/haproxy/configuration/frontends?version=1"
{"code":400,"message":"14: ERR transactionId=5636c5df-8f09-4b61-b73f-02a044f4d5e7 "}

Enabling debug-level logging in the dataplane service didn't reveal the cause of this error either:

# /usr/bin/dataplaneapi --host 0.0.0.0 --port 5555 --haproxy-bin /usr/bin/haproxy --config-file /etc/haproxy/haproxy.cfg --reload-cmd "systemctl reload haproxy" --reload-delay 5 --userlist dataplane-api --log-to=stdout --log-level=debug
time="2019-08-26T13:38:54Z" level=info msg="HAProxy Data Plane API v1.2.2 d5bbf85"
time="2019-08-26T13:38:54Z" level=info msg="Build from: [email protected]:haproxytech/dataplaneapi.git"
time="2019-08-26T13:38:54Z" level=info msg="Build date: 2019-08-21T18:06:31"
time="2019-08-26T13:38:54Z" level=info msg="Serving data plane at http://[::]:5555"
time="2019-08-26T13:38:58Z" level=info msg="started handling request" method=POST remote="10.0.2.2:49980" request="/v1/services/haproxy/configuration/frontends?version=1"
time="2019-08-26T13:38:58Z" level=info msg="completed handling request" length=85B status=400 took=1.344026ms

The lack of error message or log messages pointing to the cause lead to this issue taking much longer to diagnose than it should have. Increased logging and validation of command line arguments would help in the future.

Edit: For reference, this was with Data Plane v1.2.2 and HAProxy 2.0.5 on CentOS 7.

[mjuraga]

This definitely needs to be fixed. Thank you for your report.

[oliwer]

Pretty sure this has been fixed here https://github.com/haproxytech/client-native/commit/5ab773ceb5682249bb522befc5013cb9a18c87cf