Patrick, Am 29.04.19 um 20:37 schrieb Patrick Hemmer: > Yes, we use Type=notify. The problem though is that systemd is reporting > reload success even if the reload fails. > > Take the following example config: > > global > stats socket /tmp/foo > > With the current systemd file provided by haproxy, I copied it as > "haproxy-test.service" and modified one line to the following: > > Environment="CONFIG=/tmp/haproxy.cfg" "PIDFILE=/run/haproxy-test.pid" > > And started haproxy: > > # systemctl start haproxy-test.service > -- Logs begin at Thu 2019-04-11 15:13:39 EDT. -- > Apr 29 14:24:14 fll2albs01qa2 systemd[1]: Starting HAProxy Load Balancer... > Apr 29 14:24:14 fll2albs01qa2 haproxy[27702]: [NOTICE] 118/142414 > (27702) : New worker #1 (27704) forked > Apr 29 14:24:14 fll2albs01qa2 systemd[1]: Started HAProxy Load Balancer. > > I then edited the config and changed the stats socket line to: > > stats socket /notmp/foo > > And then tried a reload: > # systemctl reload haproxy-test.service > -- Logs begin at Thu 2019-04-11 15:13:39 EDT. -- > Apr 29 14:24:47 fll2albs01qa2 haproxy[27702]: [WARNING] 118/142447 > (27702) : Reexecuting Master process > Apr 29 14:24:47 fll2albs01qa2 haproxy[27702]: [ALERT] 118/142447 (27702) > : Starting frontend GLOBAL: cannot bind UNIX socket [/notmp/foo] > Apr 29 14:24:47 fll2albs01qa2 haproxy[27702]: [WARNING] 118/142447 > (27702) : Reexecuting Master process in waitpid mode > Apr 29 14:24:47 fll2albs01qa2 haproxy[27702]: [WARNING] 118/142447 > (27702) : Reexecuting Master process > Apr 29 14:24:47 fll2albs01qa2 systemd[1]: Reloaded HAProxy Load Balancer. > > # systemctl status haproxy-test.service > ● haproxy-test.service - HAProxy Load Balancer > Loaded: loaded (/etc/systemd/system/haproxy-test.service; disabled; > vendor preset: disabled) > Active: active (running) since Mon 2019-04-29 14:24:14 EDT; 45s ago > Process: 28335 ExecReload=/bin/kill -USR2 $MAINPID (code=exited, > status=0/SUCCESS) > Process: 28334 ExecReload=/usr/sbin/haproxy -f $CONFIG -c -q > (code=exited, status=0/SUCCESS) > Process: 27700 ExecStartPre=/usr/sbin/haproxy -f $CONFIG -c -q > (code=exited, status=0/SUCCESS) > Main PID: 27702 (haproxy) > Memory: 2.9M > CGroup: /system.slice/haproxy-test.service > ├─27702 /usr/sbin/haproxy -Ws -f /tmp/haproxy.cfg -p > /run/haproxy-test.pid -sf 27704 > └─27704 /usr/sbin/haproxy -Ws -f /tmp/haproxy.cfg -p > /run/haproxy-test.pid > > Note that the reload failed, but systemd reports success.
One issue here is that this problem was not detected by the configuration check (for obvious reasons), most problems (fat fingered configuration) are detected using the check. Regarding the sd_notify integration: I guess this is a 'bug' within the sd_notify integration. HAProxy reports READY=1 back to systemd, even if the startup failed and it falls back to waitpid mode. Possibly the ERRNO= return should be used here (I did not check whether that actually does the right thing): https://www.freedesktop.org/software/systemd/man/sd_notify.html#ERRNO=%E2%80%A6 Best regards Tim Düsterhus > With older versions of haproxy (<1.8) we had a script which checked the > PID of the master process and that it changed after sending SIGUSR2. > This strategy no longer works. >
