Hi Hans,
I've tested this as follows:
lxc exec ubuntu:xenial tester && lxc exec tester bash
apt update && apt dist-upgrade -y && apt install -y haproxy
service haproxy restart
chmod -x /usr/sbin/haproxy
service haproxy restart
Job for haproxy.service failed because the control process exited with error
code. See "systemctl status haproxy.service" and "journalctl -xe" for details.
root@tester:~# /etc/init.d/haproxy status
root@tester:~# echo $?
0
The issue isn't the pidfile check, but rather the executable check on
line 21:
test -x $HAPROXY || exit 0
Commenting that line yields:
root@tester:~# /etc/init.d/haproxy status
● haproxy.service - HAProxy Load Balancer
Loaded: loaded (/lib/systemd/system/haproxy.service; enabled; vendor preset:
enabled)
Active: failed (Result: start-limit-hit) since Wed 2019-01-09 12:56:15 UTC;
4min 1s ago
Docs: man:haproxy(1)
file:/usr/share/doc/haproxy/configuration.txt.gz
Process: 6478 ExecStartPre=/usr/sbin/haproxy -f ${CONFIG} -c -q (code=exited,
status=203/EXEC)
Main PID: 6404 (code=exited, status=0/SUCCESS)
Jan 09 12:56:15 tester systemd[1]: haproxy.service: Control process exited,
code=exited status=203
Jan 09 12:56:15 tester systemd[1]: Failed to start HAProxy Load Balancer.
Jan 09 12:56:15 tester systemd[1]: haproxy.service: Unit entered failed state.
Jan 09 12:56:15 tester systemd[1]: haproxy.service: Failed with result
'exit-code'.
Jan 09 12:56:15 tester systemd[1]: haproxy.service: Service hold-off time over,
scheduling restart.
Jan 09 12:56:15 tester systemd[1]: Stopped HAProxy Load Balancer.
Jan 09 12:56:15 tester systemd[1]: haproxy.service: Start request repeated too
quickly.
Jan 09 12:56:15 tester systemd[1]: Failed to start HAProxy Load Balancer.
Jan 09 12:56:15 tester systemd[1]: haproxy.service: Unit entered failed state.
Jan 09 12:56:15 tester systemd[1]: haproxy.service: Failed with result
'start-limit-hit'.
root@tester:~# echo $?
3
So /etc/init.d/haproxy needs a nonzero return code on line 21.
Can you check if this is the case upstream as well?
** Changed in: haproxy (Ubuntu)
Status: New => Confirmed
** Tags added: bitesize
--
You received this bug notification because you are a member of Ubuntu
High Availability Team, which is subscribed to haproxy in Ubuntu.
https://bugs.launchpad.net/bugs/1810926
Title:
initscript status check is too fragile
Status in haproxy package in Ubuntu:
Confirmed
Bug description:
`/etc/init.d/haproxy status` will return 0 if the pidfile is present,
regardless of whether haproxy is actually running.
I suggest for the check to be rewritten to actually look for a process with
that PID (e.g. `pgrep -F $PIDFILE`).
How to reproduce:
chmod -x /usr/sbin/haproxy
service haproxy restart
Result:
RC of `service haproxy status` is 3, but RC of `/etc/init.d/haproxy status`
is 0
Impact:
The initscript is used as a LSB RA for pacemaker deployments; this bug
effectively prevents pacemaker from realizing that haproxy is down (in some
cases).
Tested on:
root@juju-8d5e58-14:~# lsb_release -rd
Description: Ubuntu 16.04.5 LTS
Release: 16.04
root@juju-8d5e58-14:~# dpkg -s haproxy | grep Version
Version: 1.6.3-1ubuntu0.1
This bug is present in the most recent debian package upstream as well
(1.9.0-1), but I think it would make sense to track this here first as
we have a lot of OpenStack installations on Xenial that would benefit
from receiving a fix.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/haproxy/+bug/1810926/+subscriptions
_______________________________________________
Mailing list: https://launchpad.net/~ubuntu-ha
Post to : [email protected]
Unsubscribe : https://launchpad.net/~ubuntu-ha
More help : https://help.launchpad.net/ListHelp
