❦ 19 février 2020 13:55 +13, Michael Hudson-Doyle <michael.hudson@canonical.com>:
> So in Ubuntu we got this interesting bug
> https://bugs.launchpad.net/ubuntu/+source/haproxy/+bug/1855140 which can be
> summarized as saying that haproxy doesn't work out of the box in a docker
> container, because it installs a tmpfiles.d snippet but nothing processes
> it (I haven't tried, but I very much expect that the behaviour is the same
> between Debian and Ubuntu here).
The shipped init script contains the appropriate code to create
/run/haproxy. If the user is using the systemd unit file, the directory
was created by tmpfiles.d. If they are using the init script, the
directory is created by the init script. If the user uses neither of
them, there is not much we can do. We cannot create this directory at
install time, since /run can be wiped out on boot (the fact Docker
doesn't do that is likely an implementation detail).
> But the approach I outlined seems simplest and easiest to implement. Does
> it make sense to people here? I can try to work on a patch (although my
> perl isn't the greatest).
The simplest path would be to not do anything. Docker users can add "RUN
install -d -m 2775 -o haproxy -g haproxy /run/haproxy" in their
Dockerfile or work on a solution where the tmpfiles present in the image
are processed when spawning the image (like the fact that
`/etc/resolv.conf` is updated to match the current network
configuration). Adding more non-declarative stuff in postinst scripts
does not seem a good solution for me.
--
Don't stop at one bug.
- The Elements of Programming Style (Kernighan & Plauger)
Attachment:
signature.asc
Description: PGP signature