docker-library / haproxy

Docker Official Image packaging for HAProxy
http://www.haproxy.org/
GNU General Public License v2.0
347 stars 158 forks source link

"ltime" converter does not reflect container timezone #217

Open yolabingo opened 10 months ago

yolabingo commented 10 months ago

ltime reports the server timezone as UTC regardless of what is set as the TZ environment variable in the container.

Adding the tzdata package to the image appears to resolve this issue.

tianon commented 7 months ago

Does HAProxy intentionally support the TZ environment variable in this way, or is this more incidental? The shared link just says "local time" with no indication of how "local time" is determined (which is often via /etc/localtime).

yolabingo commented 7 months ago

HA Proxy needs to be able to get timezone data from the OS, which is provided by the tzdata package in Debian and Alpine.

Setting the TZ environment variable is a POSIX-compliant way to set the system timezone, and it is commonly used when running containers. See https://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html

Creating /etc/localtime as a symlink to a zoneinfo file is another way to set the system timezone

lrwxrwxrwx 1 root root 36 Dec 12 00:18 /etc/localtime -> /usr/share/zoneinfo/America/New_York

but this obviously still requires the tzdata package which provides the files in /usr/share/zoneinfo

tianon commented 7 months ago

Right, sorry, let me be more specific -- is this an intentional feature of HAProxy, or an incidental one? How common of a use case is it to use "local time" within HAProxy?

My references to /etc/localtime were not suggesting it should be a symlink to other files within the container (which as you've noted, would require tzdata), but rather bind-mounted from the host where "local time" typically means something more than it does inside containers and thus wouldn't need to be a symlink at all (and wouldn't need to add the extra unremovable package of tzdata which most users likely aren't going to do much with).

In general, we avoid adding things to images we maintain which are not in common or explicit upstream recommended usage especially because it's easy for end users to install, but if we pre-install it, it's very difficult for them to remove (due to the nature of container image layering).

yolabingo commented 7 months ago

I would say this is intentional. I do understand the need to keep containers as simple as possible. In my opinion, an image should include all OS packages required to run the core service, so this HAProxy docker image is broken without the tzdata package.

The HA Proxy feature ltime seems to require tzdata to function. https://docs.haproxy.org/dev/configuration.html#7.3.1-ltime

[ltime] converts an integer supposed to contain a date 
since epoch to a string representing this date in local time

Without tzdata installed, HAProxy ltime returns incorrect values. HAProxy does not issue warnings about missing zoneinfo files. It is not at all obvious to users of this image why ltime is broken. I don't know if other HAProxy features require tzdata.

I think the best solution is to add tzdata. Perhaps a reasonable alternative would be to document that this image does not support ltime and why.