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?

Improve this question
2
  • 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. docs.linuxserver.io/… Commented Dec 21, 2020 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) Commented Dec 27, 2020 at 11:05

1 Answer 1

Reset to default
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
Improve this answer
1
  • You are my hero! Worked! Commented May 3, 2021 at 20:49

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.