What do you need help with?

HAProxy Not Loading conf.d After Updates (Systemd Service File Fix)

Taylor Walton

14-Jan-2026

HAProxy Not Loading `conf.d` After Updates (Systemd Service File Fix)

This knowledgebase article documents a common onboarding failure where HAProxy is running, but it is not loading customer configs from the expected /etc/haproxy/conf.d directory. This can happen after an apt update && upgrade (or package upgrade) that overwrites the HAProxy systemd service definition.

Symptoms

During customer onboarding, the client cannot connect even after firewall ports appear correct. Investigation may reveal:

No expected listening ports on the external proxy (HAProxy)
Customer HAProxy config exists (or was manually copied) but is not being loaded
systemctl restart haproxy does not resolve the issue

You may also see that the service appears to reference the conf.d directory, but the underlying ExecStart configuration is not actually loading it as intended (often due to an overwritten service file).

Root Cause

An OS/package upgrade can overwrite haproxy.service (systemd unit file). When this occurs, HAProxy may revert to loading only a single config file (for example /etc/haproxy/haproxy.cfg) and ignore the /etc/haproxy/conf.d directory where customer-specific configs are written.

In the referenced incident, HAProxy onboarding configs were present, but the HAProxy service definition was no longer loading the conf.d directory correctly, preventing ports from binding as expected.

Fix Overview

Update the HAProxy systemd service file to explicitly load configuration from:

/etc/haproxy/haproxy.cfg (base config, optional)
/etc/haproxy/conf.d (customer-specific configs)

Then reload the systemd daemon and restart HAProxy.

Commands Used

nano /lib/systemd/system/haproxy.service

systemctl daemon-reload
systemctl restart haproxy
netstat -tlpnd

Step-by-Step Procedure

1) Edit the HAProxy systemd Unit File

Open the HAProxy service file:

nano /lib/systemd/system/haproxy.service

Update the [Service] section so HAProxy loads the config directory. Below is a working example that defines CONFIGDIR and uses it in ExecStart / ExecReload.

2) Use the Following Service File Contents

[Unit]
Description=HAProxy Load Balancer
Documentation=man:haproxy(1)
Documentation=file:/usr/share/doc/haproxy/configuration.txt.gz
After=network-online.target rsyslog.service
Wants=network-online.target

[Service]
EnvironmentFile=-/etc/default/haproxy
EnvironmentFile=-/etc/sysconfig/haproxy
BindReadOnlyPaths=/dev/log:/var/lib/haproxy/dev/log
Environment="CONFIG=/etc/haproxy/haproxy.cfg" "CONFIGDIR=/etc/haproxy/conf.d" "PIDFILE=/run/haproxy.pid" "EXTRAOPTS=-S /run/haproxy-master.sock"
ExecStart=/usr/sbin/haproxy -Ws -f $CONFIGDIR -p $PIDFILE $EXTRAOPTS
ExecReload=/usr/sbin/haproxy -Ws -f $CONFIGDIR -c -q $EXTRAOPTS
ExecReload=/bin/kill -USR2 $MAINPID
KillMode=mixed
Restart=always
SuccessExitStatus=143
Type=notify

# The following lines leverage SystemD's sandboxing options to provide
# defense in depth protection at the expense of restricting some flexibility
# in your setup (e.g. placement of your configuration files) or possibly
# reduced performance. See systemd.service(5) and systemd.exec(5) for further
# information.

# NoNewPrivileges=true
# ProtectHome=true
# If you want to use 'ProtectSystem=strict' you should whitelist the PIDFILE,
# any state files and any other files written using 'ReadWritePaths' or
# 'RuntimeDirectory'.
# ProtectSystem=true
# ProtectKernelTunables=true
# ProtectKernelModules=true
# ProtectControlGroups=true
# If your SystemD version supports them, you can add: @reboot, @swap, @sync
# SystemCallFilter=~@cpu-emulation @keyring @module @obsolete @raw-io

[Install]
WantedBy=multi-user.target

Notes:

-f can point to a directory or file. In this configuration we point it at /etc/haproxy/conf.d.
If you require both the base config and the directory, you can pass multiple -f arguments (example: -f $CONFIG -f $CONFIGDIR). Only change this if your environment expects it.

3) Reload systemd and Restart HAProxy

After saving the file, reload systemd to pick up the updated unit definition:

systemctl daemon-reload

Restart HAProxy:

systemctl restart haproxy

4) Validate Listening Ports

Confirm HAProxy is now binding to the expected ports:

netstat -tlpnd

If HAProxy is loading the customer configs correctly, you should now see the expected SIEM stack ports in a LISTEN state on the proxy host.

What “Good” Looks Like

Once fixed, customer onboarding should proceed normally and HAProxy should listen on the ports required by the stack (Wazuh registration, Wazuh agent comms, etc.). If onboarding still fails after ports are listening: