Home / server / Questions / 1037146
Accepted
Filipe Pina
Asked: 2020-10-10 16:21:38 +0800 CST

Docker container with random date

  • 772

I was running a container based on the image linuxserver/radarr:3.0.0.3095-ls12.
Once I updated the tag/version to linuxserver/radarr:3.0.0.3807-ls24 the application stopped working.

After debugging a little I noticed that date behaves weirdly in this image:

$ docker run --rm --entrypoint "" linuxserver/radarr:3.0.0.3807-ls24 date
Fri 20 Feb 1970 03:17:15 AM UTC
$ docker run --rm --entrypoint "" linuxserver/radarr:3.0.0.3807-ls24 date
Sun 01 Mar 1970 09:09:15 AM UTC
$ docker run --rm --entrypoint "" linuxserver/radarr:3.0.0.3807-ls24 date
Thu 19 Feb 1970 09:04:59 AM UTC

But the old doesn't

$ docker run --rm --entrypoint "" linuxserver/radarr:3.0.0.3095-ls12 date
Sat 10 Oct 2020 12:15:09 AM UTC

After meditating for a while, assuming some kind of weird dark magic in the clock, decided to run it with --privileged for full/raw access

$ docker run --rm --entrypoint "" --privileged linuxserver/radarr:3.0.0.3807-ls24 date
Sat 10 Oct 2020 12:16:22 AM UTC

And it worked well (and so did the app, but not important to the question).

I have gone through docker history of both images but a lot of COPY and RUN curl that might have different results between builds. Still, I don't think anyone (image maintainers) would want to mangle with the date, so it must be something out of their control (no libfaketime found)...

This is a multi-arch image and these results are from a raspberry Pi (so the arm build of the image). In my amd64 linux laptop, the latest image reports proper date even without privileged...

What could it be? How can I even start to debug this as I cannot use the --privileged flag?

docker containers date

1 Answers

  1. Best Answer

    Following up on Adrian's comment (which should have been an answer):

    According the linuxserver FAQ this is a known issue with docker and ubuntu focal images since March 2020.

    It seems it is related to outdated libseccomp (the only dependency from Docker besides kernel itself) which explains why a privileged container was not affected (syscall filtering disabled).

    They list possible resolution steps.
    In my case (as OP), I'm using Buster, so installing an up to date libseccomp from buster-backports solved the issue

     sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 04EE7237B7D453EC 648ACFD622F3D138
 echo "deb http://deb.debian.org/debian buster-backports main" | sudo tee -a /etc/apt/sources.list.d/buster-backports.list
 sudo apt update
 sudo apt install -t buster-backports libseccomp2
    • 3