1

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?

Filipe Pina
  • 123
  • 8
  • 2
    Same thing happened to me with that container and also after updating linuxserver/jellyfin image. The problem only happens with ARM (raspberry pi 4B in my case). I tried changing the date with all known methods to no success. Finally, I found a blog post on linuxserver blog addressing the issue. They offer a set of solutions. I haven't tested them yet, but I'm sure they will work. https://docs.linuxserver.io/faq#my-host-is-incompatible-with-images-based-on-ubuntu-focal – Adrian Dec 21 '20 at 12:08
  • Didn’t you put this up as answer? I was going to accept it once I tried it (haven’t had the chance yet) – Filipe Pina Dec 27 '20 at 11:05

1 Answers1

3

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
Filipe Pina
  • 123
  • 8