Odd, this clearly works for me in a new system

# ll /run/haproxy
ls: cannot access '/run/haproxy': No such file or directory
root@b:~# apt install haproxy
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following package was automatically installed and is no longer required:
  libfreetype6
Use 'apt autoremove' to remove it.
The following additional packages will be installed:
  liblua5.3-0
Suggested packages:
  vim-haproxy haproxy-doc
The following NEW packages will be installed:
  haproxy liblua5.3-0
0 upgraded, 2 newly installed, 0 to remove and 9 not upgraded.
Need to get 1231 kB of archives.
After this operation, 2842 kB of additional disk space will be used.
Do you want to continue? [Y/n] Y
Get:1 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 liblua5.3-0 
amd64 5.3.3-1ubuntu0.18.04.1 [115 kB]
Get:2 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 haproxy amd64 
1.8.8-1ubuntu0.9 [1117 kB]
Fetched 1231 kB in 1s (2143 kB/s)
Selecting previously unselected package liblua5.3-0:amd64.
(Reading database ... 28651 files and directories currently installed.)
Preparing to unpack .../liblua5.3-0_5.3.3-1ubuntu0.18.04.1_amd64.deb ...
Unpacking liblua5.3-0:amd64 (5.3.3-1ubuntu0.18.04.1) ...
Selecting previously unselected package haproxy.
Preparing to unpack .../haproxy_1.8.8-1ubuntu0.9_amd64.deb ...
Unpacking haproxy (1.8.8-1ubuntu0.9) ...
Setting up liblua5.3-0:amd64 (5.3.3-1ubuntu0.18.04.1) ...
Setting up haproxy (1.8.8-1ubuntu0.9) ...
Created symlink /etc/systemd/system/multi-user.target.wants/haproxy.service → 
/lib/systemd/system/haproxy.service.
Processing triggers for libc-bin (2.27-3ubuntu1) ...
Processing triggers for systemd (237-3ubuntu10.31) ...
Processing triggers for man-db (2.8.3-2ubuntu0.1) ...
Processing triggers for rsyslog (8.32.0-1ubuntu4) ...
Processing triggers for ureadahead (0.100.0-21) ...
root@b:~# ll /run/haproxy
total 0
drwxrwsr-x  2 haproxy haproxy  60 Dec  6 12:03 ./
drwxr-xr-x 19 root    root    740 Dec  6 12:03 ../
srw-rw----  1 root    haproxy   0 Dec  6 12:03 admin.sock=


Directory is created on package install and the service running.

So it really comes down to /usr/lib/tmpfiles.d/* not working in docker ?!
There is much more than just haproxy in there, not being able to rely on it at 
all would totally disable that feature and all packages would need to be 
modified.
I don't think we'd do that but also have no perfect answer for you.

Personal opinion: if you want to use the container as a system-container
instead of a microservice then use a proper system container service
like LXD instead of docker.

I'll need to talk to a few people about that to gather more opinions
about what we want to do for tmpfiles.d here.

** Tags added: server-triage-discuss

-- 
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/1855140

Title:
  haproxy package misses creation of default stats socket path

Status in haproxy package in Ubuntu:
  New

Bug description:
  When installing the haproxy package from the current Ubuntu 18.04
  Bionic repos, the package does not install the directory /run/haproxy.
  This directory is mentioned in the default config file
  /etc/haproxy/haproxy.cfg:

   stats socket /run/haproxy/admin.sock mode 660 level admin expose-fd
  listeners

  Starting HAProxy manually will show the following error:

  # /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg
  [ALERT] 337/154339 (24) : Starting frontend GLOBAL: cannot bind UNIX socket 
[/run/haproxy/admin.sock]

  After manual creation of the directory, the start works:

  # mkdir /run/haproxy

  # /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg

  # ps auxf
  USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
  root        10  0.1  0.0  18616  3416 pts/0    Ss   15:42   0:00 /bin/bash
  root        32  0.0  0.0  34400  2900 pts/0    R+   15:45   0:00  \_ ps auxf
  root         1  0.0  0.0  18376  3016 ?        Ss   15:40   0:00 bash 
/root/entrypoint.sh
  haproxy     31  0.0  0.0  54284  1252 ?        Ss   15:45   0:00 
/usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg

  This can be reproduced with a simple Docker container the following
  Dockerfile:

  ----------------------------------------------
  FROM ubuntu:18.04
  MAINTAINER Claudio Kuenzler <[email protected]>

  # install packages
  RUN apt-get update \
    && apt-get install -y -qq haproxy

  CMD ["/usr/sbin/haproxy","-f","/etc/haproxy/haproxy.cfg"]
  ----------------------------------------------

  Checking the haproxy package for the run directory shows nothing:

  # dpkg -L haproxy | grep run ; date
  Wed Dec  4 15:58:52 UTC 2019

  *******************************************

  Update: After analysis of the haproxy package (see
  https://www.claudiokuenzler.com/blog/917/haproxy-ubuntu-18.04-docker-
  image-not-starting-cannot-bind-unix-socket), it turns out that the
  /run/haproxy directory is defined in debian/haproxy.tmpfile. However
  tmpfile's are only considered in systems with SystemD. As Docker
  containers run without Systemd, this directory is never created.

  Suggestion: Do not rely on Systemd to create /run/haproxy. Maybe use
  debian/haproxy.dirs? However the permissions are not set in this case.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/haproxy/+bug/1855140/+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

Reply via email to