Suddenly Thu Jan 1 01:00:00 CET 1970 in container

Help Community Help
1

I'n not really sure what happened, but suddenly, the pihole shows a date of Thu Jan 1 01:00:00 CET 1970 in the log files (and thus as well a lot of errors when it tries to validate dnssec certificates). I've broken that down to the fact that the container actually has that date

host:# date
Mon 04 Apr 2022 11:06:42 AM CEST
host:# docker exec -u 0 -it pihole /bin/bash 
root@34121463a036:/# date
Thu Jan  1 01:00:00 CET 1970
host:# docker ps                             
88cd2199857b   pihole/pihole:latest           "/s6-init"               18 hours ago   Up 9 minutes (unhealthy)   0.0.0.0:53->53/udp, :::53->53/udp, 0.0.0.0:53->53/tcp, :::53->53/tcp, 0.0.0.0:80->80/tcp, 0.0.0.0:67->67/udp, :::80->80/tcp, :::67->67/udp   pihole

I've tried restarting the container, but it sticks to "unhealthy".
Anything else I could do?

2

I have recreated the container from scratch. Same problem.
On the other hand, I have other containers running on the same machine where the date is correct,

3

This seems to be related to Docker and the OS it runs on rather than Pi-hole:
Docker seems unable to provide the correct time for your container.

Are you able to manually set the time from within your Pi-hole container?

date -s "04 APR 2022 20:00:00"
1 Like
5

:/# date -s "04 APR 2022 22:43:00"
date: cannot set date: Operation not permitted
Mon Apr 4 22:43:00 CEST 2022

But - as written above: in another container, date and time are correct.

6

I'd guess that other container's image to be based on another OS.

A precursory search for your observation of an epoch zero time in containers reveals that you may be affected by the following Docker issue, where one of Docker's dependencies restricts Docker from accessing certain OS side information (e.g. time):

EDIT:
I am in no way an expert when it comes to Docker internals, but in an attempt to explain what this is about:
From what I glance from skimming that issue, system level calls from the OS within a container are filtered by Docker before being passed to the host OS of the machine running Docker.
For that purpose, Docker is relying on another package seccomp. Now, for certain host OSs, that package is failing to match the system call of the container OS to the host OS, resulting in incorrect behaviour, while other container OS/seccomp/host OS combinations may work.

In that case, following the link to FAQ - LinuxServer.io provides a few suggestions for potential fixes.

1 Like
7

I was sort of hoping the answer would be that angrest created a time machine.

1 Like
8

Great - thank you, that helped.
Indeed I had already the backports source configured as explained in the linked article, but for some unknown reason, the updates were not detected. Suddenly, I had about 40 packages to update and afterward, the time in the container is again correct.

9

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.