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?
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,
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): https://github.com/moby/moby/issues/40734
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 Redirecting... provides a few suggestions for potential fixes.
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.