[trusty] haproxy does not start after reboot due to missing rundir (/var/run/haproxy)

[Trent Lloyd]

haproxy does not start after reboot on trusty, because /var/run/haproxy doesn't exist which is used for the admin socket by the charm configuration (/var/run/haproxy/admin.sock)

This error is not logged (for some reason I have not looked into), but you can see the failure and the error messaged logged with strace.

This works on initial deployment, and when you try to manually start haproxy, because the charm has code to create this directory (and that code is executed on reboot, but after the initial attempt to start haproxy, so it is left stopped). Unfortunately /var/run is a tmpfs and is purged on reboot.

On xenial, the init script creates this directory for you, on trusty it does not.
It appears on trusty, the "intended" socket path was /var/run/haproxy.sock (no subdirectory) so that would work without this directory creation.

As best I can tell, nothing inside the charm ecosystem consumes this path. However it is an 'external' API and perhaps some charm deployed system or other charm depends on this path. I couldn't find any evidence of that but it's hard to be sure.

Given that the system not starting on reboot is a fairly serious issue - I see 3 solutions to this problem.

(1) We update the charm code to conditionally set this path based on the distribution version, and make it /var/run/haproxy.sock on trusty.

(2) We update the charm to ship a second startup script (before haproxy in the init order, or with an upstart before dependency) to create the directory

(3) We SRU the trusty haproxy package to create this runpath in the init script, bearing in mind that nothing in the default Ubuntu configuration or examples use this path -- only the charm uses this path based on what it writes into the config file

My feeling is that (1) is the cleanest choice with a small but possible chance of breaking some installations if they were relying on this socket path, making (2) the best choice as it has the smallest chance of breakage and (3) is not a good idea since the original package never intends to use this directory

I am happy to make a pull request for this but I wanted to get some input that my suggestion (2) is really the best choice or whether we should go for (1) or some other option.