Comment 0 for bug 1755061

Paul Collins (pjdc) wrote :

While testing upgrades of an Ubuntu 14.04 deployment of OpenStack from ~15.04 to 17.11 charms, I noticed that a number of the OpenStack charmed services failed to start haproxy when I rebooted their units: cinder, glance, keystone, neutron-api, nova-cloud-controller, and swift-proxy.

The following was in /var/log/boot.log:

[ALERT] 069/225906 (1100) : cannot bind socket for UNIX listener (/var/run/haproxy/admin.sock). Aborting.
[ALERT] 069/225906 (1100) : [/usr/sbin/haproxy.main()] Some protocols failed to start their listeners! Exiting.
 * Starting haproxy haproxy [fail]

The charm created /var/run/haproxy, but since /var/run (really /run) is a tmpfs, this did not survive the reboot and so haproxy could not create the socket.

I compared the haproxy.cfg the charm creates with the default config shipped by the Ubuntu 16.04 haproxy package, and it seems that charmhelpers/contrib/openstack/templates/haproxy.cfg is closely based on the package, including the admin.sock directive. However, on Ubuntu 16.04, /etc/init.d/haproxy ensures that /var/run/haproxy exists before it starts haproxy:

[agnew(work)] diff -u haproxy-1.4.24/debian/haproxy.init haproxy-1.6.3/debian/haproxy.init
--- haproxy-1.4.24/debian/haproxy.init 2015-12-16 03:55:29.000000000 +1300
+++ haproxy-1.6.3/debian/haproxy.init 2015-12-31 20:10:38.000000000 +1300
@@ -50,6 +41,10 @@

+ [ -d "$RUNDIR" ] || mkdir "$RUNDIR"
+ chown haproxy:haproxy "$RUNDIR"
+ chmod 2775 "$RUNDIR"

        start-stop-daemon --quiet --oknodo --start --pidfile "$PIDFILE" \

charm-helpers or the OpenStack charms or both should be updated so that haproxy will start on boot when running on Ubuntu 14.04.