In Docker with compose there is a issue where date cannot be pulled

RonV42 · April 11, 2022, 6:07pm

Please follow the below template, it will help us to help you!

I have been running for about 2 years docker-compose with Pi-hole and just did a pull and updated. After the update I am getting errors where the container can't get the current date and is returning errors:

pihole      | [1969-12-31 19:00:51.-1225030 497M] DB warn: TIMESTAMP should be larger than 01/01/2017 but is 6
pihole      | [1969-12-31 19:00:51.-sudo: unable to get time of day: Operation not permitted
pihole      | sudo: error initializing audit plugin sudoers_audit

The query log is showing tha it's 1969:

The DNS is resolving but never seen this happen before with docker and I have 3 other instances running with the same configs on various Synolgoy devices and not seeing this.

Update:

I found this article:

The reason I found this article is that I found CRON using 100% CPU when running Pi-hole in the container. The resolution was to run a backport of libseccomp2.

Here is where I got the instructions for the back port:

github.com/pi-hole/docker-pi-hole

Cron uses 100% CPU with 2022.04 on Raspberry

opened 10:38AM - 02 Apr 22 UTC

closed 04:05PM - 03 Apr 22 UTC

mhavelant

This is a: Bug ## Details I updated from 2022.02.1 to 2022.04 just now, and noticed 100% CPU usage for the container. Reverting to 2022.02.1 fixed it. ## Related Issues - [x] I have searched this repository/Pi-hole forums for existing issues and pull requests that look similar ## How to reproduce the issue 1. Environment data * Operating System: Raspbian (Linux raspberrypi 5.10.103-v7+) * Hardware: RasPi 3B * Kernel Architecture: armv7l * Docker Install Info and version: - Software source: Official docker-ce 20.10.14 - Supplimentary Software: Docker Compose v2.3.3; docker swarm * Hardware architecture: ARMv7 2. docker-compose.yml contents, docker run shell command, or paste a screenshot of any UI based configuration of containers here 3. any additional info to help reproduce Test-running it with `docker run -d --name tmppihole pihole/pihole:2022.04` Output of `docker top`: ``` UID PID PPID C STIME TTY TIME CMD root 24181 24152 0 11:45 ? 00:00:00 s6-svscan -t0 /var/run/s6/services root 24302 24181 0 11:45 ? 00:00:00 s6-supervise s6-fdholderd root 24834 24181 0 11:46 ? 00:00:00 s6-supervise lighttpd root 24835 24181 0 11:46 ? 00:00:00 s6-supervise pihole-FTL root 24836 24181 0 11:46 ? 00:00:00 s6-supervise lighttpd-access-log root 24837 24181 0 11:46 ? 00:00:00 s6-supervise cron root 24838 24181 0 11:46 ? 00:00:00 s6-supervise lighttpd-error-log root 24842 24834 0 11:46 ? 00:00:00 bash ./run root 24865 24837 0 11:46 ? 00:00:00 bash ./run www-data 24870 24842 0 11:46 ? 00:00:00 lighttpd -D -f /etc/lighttpd/lighttpd.conf root 24875 24865 99 11:46 ? 00:00:40 /usr/sbin/cron -f www-data 24896 24870 0 11:46 ? 00:00:00 /usr/bin/php-cgi www-data 24907 24896 0 11:46 ? 00:00:00 /usr/bin/php-cgi www-data 24908 24896 0 11:46 ? 00:00:00 /usr/bin/php-cgi www-data 24909 24896 0 11:46 ? 00:00:00 /usr/bin/php-cgi www-data 24910 24896 0 11:46 ? 00:00:00 /usr/bin/php-cgi ``` With the most relevant line being ``` root 24875 24865 99 11:46 ? 00:00:40 /usr/sbin/cron -f ``` Output of `docker stats`: ``` 29ae0076388a tmppihole 106.11% 10.32MiB / 966.8MiB 1.07% 75.1kB / 8.78kB 0B / 0B 16 ``` I waited for about 10-15 minutes, hoping it's just some long-running startup thing, but no luck, still 100% CPU usage. Tried it on my main machine, Pop!_OS 21.04, it seems to work there better. ## These common fixes didn't work for my issue - [x] I have tried removing/destroying my container, and re-creating a new container - [x] I have tried fresh volume data by backing up and moving/removing the old volume data - [x] I have tried running the stock `docker run` example(s) in the readme (removing any customizations I added) - [x] I have tried a newer or older version of Docker Pi-hole (depending what version the issue started in for me) - [x] I have tried running without my volume data mounts to eliminate volumes as the cause If the above debugging / fixes revealed any new information note it here. Add any other debugging steps you've taken or theories on root cause that may help.

After doing the backport I am back to normal

Bucking_Horn · April 12, 2022, 6:51am

Maybe Suddenly Thu Jan 1 01:00:00 CET 1970 in container is related?

The underlying issue there was Docker, where one of Docker's dependencies restricts Docker from accessing certain OS side information for certain combinations of image OS and Docker host's OS.

RonV42 · April 12, 2022, 10:13am

Yes agreed, I am surprised that more folks that run in containers didn't see this. What seemed to be two "unrelated" issues at first glance lead me to the GitHub conversation. Time pull from the OS to CRON consuming 100% now all those pieces fell into place once I read though the problem.

system · May 3, 2022, 10:13am

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