Docker container with random date

Question

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?

Answer 1

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