0

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?

2
  • 1
    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. docs.linuxserver.io/… – 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

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
1

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.