Thanks updating status to closed as per last comment. This does sound
like it may be more of a pacemaker issue than haproxy, particularly if
it's still reproducible on a newer LTS.
** Description changed:
`/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
+ $ sudo apt-get -y install haproxy
+ $ sudo chmod -x /usr/sbin/haproxy
+ $ sudo service haproxy restart
+ $ service haproxy status
+ (...)
+ Active: failed (Result: start-limit-hit) (...)
+ (...)
+ $ echo $?
+ 3
+ $ sudo /etc/init.d/haproxy status
+ 0
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.
** Description changed:
`/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`).
+ [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).
+
+ [Test Case]
How to reproduce:
$ sudo apt-get -y install haproxy
$ sudo chmod -x /usr/sbin/haproxy
$ sudo service haproxy restart
$ service haproxy status
(...)
- Active: failed (Result: start-limit-hit) (...)
+ Active: failed (Result: start-limit-hit) (...)
(...)
$ echo $?
3
$ sudo /etc/init.d/haproxy status
0
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.
** Changed in: haproxy (Ubuntu)
Status: Confirmed => Invalid
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1810926
Title:
initscript status check is too fragile
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/haproxy/+bug/1810926/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
