Update for trusty uploaded to SRU queue for ubuntu-sru review.
** Also affects: haproxy (Ubuntu Trusty)
Importance: Undecided
Status: New
** Changed in: haproxy (Ubuntu)
Status: Triaged => Fix Released
** Changed in: haproxy (Ubuntu Trusty)
Importance: Undecided => High
** Changed in: haproxy (Ubuntu Trusty)
Status: New => In Progress
** Changed in: haproxy (Ubuntu Trusty)
Assignee: (unassigned) => James Page (james-page)
** Description changed:
- 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.
+ [Impact]
+ Valid haproxy configuration directives don't work on trusty as /run/haproxy
does not survive reboots and is not-recreated on daemon start.
+
+ [Test Case]
+ sudo apt install haproxy
+ configure /etc/haproxy.cfg with a admin socket in /run/haproxy:
+
+ global
+ log /var/lib/haproxy/dev/log local0
+ log /var/lib/haproxy/dev/log local1 notice
+ maxconn 20000
+ user haproxy
+ group haproxy
+ spread-checks 0
+ stats socket /var/run/haproxy/admin.sock mode 600 level admin
+ stats timeout 2m
+
+ Restart haproxy (will fail as /{,var/}run/haproxy does not exist)
+
+ [Regression Potential]
+ Minimal - same fix is in later package revisions
+
+ [Original Bug Report]
+ 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]
+ * 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
+ [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 @@
-
- haproxy_start()
- {
- + [ -d "$RUNDIR" ] || mkdir "$RUNDIR"
- + chown haproxy:haproxy "$RUNDIR"
- + chmod 2775 "$RUNDIR"
- +
- check_haproxy_config
-
- start-stop-daemon --quiet --oknodo --start --pidfile "$PIDFILE" \
+ @@ -50,6 +41,10 @@
+
+ haproxy_start()
+ {
+ + [ -d "$RUNDIR" ] || mkdir "$RUNDIR"
+ + chown haproxy:haproxy "$RUNDIR"
+ + chmod 2775 "$RUNDIR"
+ +
+ check_haproxy_config
+
+ 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.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1755061
Title:
HAProxyContext on Ubuntu 14.04 generates config that fails to start on
boot
To manage notifications about this bug go to:
https://bugs.launchpad.net/charm-cinder/+bug/1755061/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
