Closed lsf37 closed 4 months ago
It does appear that passing the time zone via TZ as an environment variable is more stable than trying to link the time zone file directly.
The main question is how to reliably get the time zone string from the host OS. On reasonably recent Debian, Ubuntu, and MacOS at least, the /etc/localtime
link seems to always exist, so we could try to extract it from that.
Ubuntu and Debian both seem to support reading /etc/timezone
which for me both report the correct string Australia/Sydney
. I think Debian also sets TZ
. So we could do the following in decreasing priority
TZ
env, if set use that/etc/timezone
, if the file exists use its contents/var/db/timezone/zoneinfo/
from the link in /etc/localtime
We could also delete the symlink in the container, of course. Not sure if that throws anything into disarray.
Just use TZ. It's meant to be there (POSIX standard). /etc/localtime is a GNU extension that makes things faster if it's there.
TZ is unfortunately not set on most platforms I tried (in fact, it was set only on Debian). It works when I set it in the container, but my main problem is trying to get the correct time zone string from the host.
Yes, adding MacOS support was a real spanner in the works, unfortunately :(
What does the /usr/share/zoneinfo.default/Australia/Sydney
file (or folder) look like on the host?
Otherwise, your bullet point list of options sounds fair enough.
For the timezone file itself I get the following on MacOS:
ls -l /usr/share/zoneinfo.default/Australia/Sydney
-rw-r--r-- 4 root wheel 2195 28 Oct 19:43 /usr/share/zoneinfo.default/Australia/Sydney
Before I try all that extraction stuff, I'll give it the old method another shot by deleting the symbolic link in the docker container so that there is no conflict when docker is trying to mount there. Peter mentioned that if the file/link does not exist it's just going to default to UTC which is what it's already doing anyway, so there should be no additional adverse effects if the mount command doesn't work for some reason.
Hi all, also run into the wall of getting the docker image up and running on an M1 Mac, I've set the environment var export DOCKER_BUILDKIT=0
(ran into the same issue as https://github.com/seL4/seL4-CAmkES-L4v-dockerfiles/issues/40 , when pulling extras
image), but I believe I have arrived at the same issue as this one describes:
When running make user
, fails at:
docker: Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error mounting "/usr/share/zoneinfo.default/Europe/London" to rootfs at "/etc/localtime": mount /usr/share/zoneinfo.default/Europe/London:/etc/localtime (via /proc/self/fd/9), flags: 0x5001: not a directory: unknown: Are you trying to mount a directory onto a file (or vice-versa)? Check if the specified host path exists and is the expected type.
make: *** [Makefile:131: user_run] Error 125```
For the timezone file itself I get the following on MacOS:
ls -l /usr/share/zoneinfo.default/Australia/Sydney -rw-r--r-- 4 root wheel 2195 28 Oct 19:43 /usr/share/zoneinfo.default/Australia/Sydney
Before I try all that extraction stuff, I'll give it the old method another shot by deleting the symbolic link in the docker container so that there is no conflict when docker is trying to mount there. Peter mentioned that if the file/link does not exist it's just going to default to UTC which is what it's already doing anyway, so there should be no additional adverse effects if the mount command doesn't work for some reason.
This actually seems to have worked fine, so I’m closing this issue for now.
It looks like a new form of #16 has reappeared. For
I'm getting
If I delete the time zone line and inspect the container, there is indeed already a symlink in
/etc/localtime
:This is on MacOS Ventura (13.0.1) and Docker version 20.10.21, build
baeda1f