❦ 19 février 2020 13:55 +13, Michael Hudson-Doyle <michael.hud...@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)
signature.asc
Description: PGP signature
