can't set timezone in Kodi - bind-mount /usr/share/zoneinfo? about x11docker HOT 11 CLOSED

I ran your tests and got the same results. Super confusing.

After some more research, I think I discovered the cause. Turns out that Docker has a slightly strange behavior when you perform a single-file bind-mount into a container on top of an existing symbolic link (e.g. mounting /etc/localtime into the container). Instead of replacing the link, Docker will replace the link's target file. Weird. So when we bind-mount /etc/localtime by itself, we see the following:

$ docker run -it --rm -v /etc/localtime:/etc/localtime:ro debian
  # ls -l /etc/localtime
  lrwxrwxrwx 1 root root 27 Apr 25 17:00 /etc/localtime -> /usr/share/zoneinfo/Etc/UTC
  # ls -l /usr/share/zoneinfo/Etc/UTC
  lrwxrwxrwx 1 root root 6 Mar 26 15:43 /usr/share/zoneinfo/Etc/UTC -> ../UTC
  # ls -l /usr/share/zoneinfo/UTC    
  -rw-r--r-- 1 root root 2845 May  4 11:22 /usr/share/zoneinfo/UTC
  # mount | grep zone
  /dev/mapper/sdb4_crypt on /usr/share/zoneinfo/UTC type btrfs (ro,...,subvol=/usr/share/zoneinfo/America/Los_Angeles)

In other words, the container's copy of /etc/localtime eventually points to /usr/share/zoneinfo/UTC, which is actually my host's bind-mounted /etc/localtime. All good.

Now, what happens if we additionally mount /usr/share/zoneinfo? /etc/localtime again eventually points to /usr/share/zoneinfo/UTC, so that part doesn't change. But now /usr/share/zoneinfo/UTC already exists from within /usr/share/zoneinfo mount. The single-file bind-mount of /etc/localtime to /usr/share/zoneinfo/UTC is "overridden", and the container then assumes that it lives in UTC.

For Kodi, the reason the behavior changed between Ubuntu 16.04 (Xenial) and 18.04 (Bionic) is that /usr/share/zoneinfo exists in the former, but not the latter; Bionic doesn't have its own copy of /usr/share/zoneinfo to parse.

In short, I don't think it would be wise to add -v /usr/share/zoneinfo:/usr/share/zoneinfo:ro to x11docker. Continuing to mount only /etc/localtime is the better solution.

from x11docker.

I suppose another option would be to install tzdata into the image at build time. This would negate the need for the bind-mount, but would increase the image size by a few MB. Not sure which approach is better.

from x11docker.

I did a test with -v /usr/share/zoneinfo:/usr/share/zoneinfo:ro and found that I get wrong times with other images, e.g.

x11docker --nothing --stdout -- --volume=/usr/share/zoneinfo:/usr/share/zoneinfo:ro x11docker/lxde date

I get the right time with:

x11docker --nothing --stdout x11docker/lxde date
x11docker --nothing --stdout ubuntu:18.04 date
x11docker --nothing --stdout -- --volume=/usr/share/zoneinfo:/usr/share/zoneinfo:ro ubuntu:18.04 date

Now I am confused.
I tried to add some variants of --env TZ= as suggested at http://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html, but with no success.

As the issue is specific to kodi within ubuntu 18.04, and ubuntu:18.04 has no issue with shared /usr/share/zoneinfo, I suggest to add --volume=/usr/share/zoneinfo:/usr/share/zoneinfo:ro to your kodi command instead of implementing it in x11docker, or to install tzdata in kodi image if that helps.

Though, if we find a general solution that works for other images, too, I am willing to include it in x11docker.

(OT side note: consider to register ehough and erichough on gitlab before someone else does ...).

from x11docker.

side note: consider to register ehough and erichough on gitlab before someone else does

Thanks for the reminder! Done 👍

from x11docker.

Thanks for your research! I admit I wasn't even aware that /etc/localtime is a symlink only. I once added it, was happy that it worked and forgot about it.

In short, I don't think it would be wise to add -v /usr/share/zoneinfo:/usr/share/zoneinfo:ro to x11docker. Continuing to mount only /etc/localtime is the better solution.

An experiment that at least works with my examples above: I am sharing usr/share/zoneinfo and within the container I create the symlink:

ln -f -s $(readlink /etc/localtime) /etc/localtime

I've uploaded this change in master branch. Could you try out if it works with kodi, too?

from x11docker.

That's a clever idea. I just tested 233f3ef with Kodi and it works perfectly! Seems to me like this is a good solution.

from x11docker.

it works perfectly

:-) So I will keep it in the code.

from x11docker.

Currently I am in doubt if I should keep the solution sharing /usr/share/zoneinfo from host.
It will cause trouble with images based on musl libc like alpine.

I am not sure how to solve this the best way.

Maybe I should only create the softlink /etc/localtime within container regardless if the target exists or not.

I just did a test with only providing the target file if libc from host and container match.
But kodi greyes out the timezone selection option if /usr/share/timezone only containes this single target.

I have to investigate further, just want to tell you that this may change again.

from x11docker.

I finally decided to change the timezone syncing procedure.

If host and image both are based on glibc, x11docker provides only the one file where /etc/localtime points to. (Internally using a copy instead of a shared volume because x11docker does not know whether the container runs with musl libc before it is already running).

If the targeted timezone exists in container, the symlink /etc/localtime is created in container.

If all of the above fails, environment variable TZ is set to calculate the time as an offset to UTC.

This works with debian and ubuntu bionic images as well as with alpine/musl libc.

Only kodi does not recognize the time zone settings and the provided timezone file, and the options to change it are greyed out :-(. But kodi works if tzdata is installed.

I recommend to install tzdata in kodi image instead of sharing /usr/share/timezone from host because kodi would fail if the host is based on a libc different from glibc (e.g. alpine, Void, NixOS).

from x11docker.

Thanks for this update! I tested it with Kodi (tzdata installed) and it seems to work just fine. I can't say I fully understand the details of the changes, but that's not my job, right? 😉

from x11docker.

I can't say I fully understand the details of the changes, but that's not my job, right? wink

:-) It's confusing, and I did several tries and mistakes until it worked.

Though, I think kodi itself should at least check date to set its time and date. Maybe worth a bug report.

But, feel happy we don't have issues with keyboard mapping. Keyboard settings are a real PITA. :-D

from x11docker.