docker-pi-hole

docker-pi-hole copied to clipboard

For me 2022.04.1 (Using image 334d46d0f4bd) does not fix anything. I can produce this debug log when I revert to 036a3f19f8be https://tricorder.pi-hole.net/HxlHpPSE/ Note that I'm on armhf.

On docker host:

❯ uname -a
Linux raspberrypidocker 5.10.103-v8+ #1529 SMP PREEMPT Tue Mar 8 12:26:46 GMT 2022 aarch64 GNU/Linux

Originally posted by @Mellbourn in https://github.com/pi-hole/docker-pi-hole/issues/1035#issuecomment-1086621033

Same behavior as before. Log ends with

pihole        | [services.d] done.
pihole        | sudo: unable to get time of day: Operation not permitted
pihole        | sudo: error initializing audit plugin sudoers_audit
pihole        | sudo: unable to get time of day: Operation not permitted
pihole        | sudo: error initializing audit plugin sudoers_audit
[repeated]

opened a new issue as something is off in your debug log, and I think it is either a different issue or a misconfiguration:

[i] Core: v5.9 (https://discourse.pi-hole.net/t/how-do-i-update-pi-hole/249)

That should be showing v5.9.1

Just realised you said you reverted. I'm not able to match those digest hashes to anything on docker hub? Where are you getting that from?

What does your run command/compose file look like?

Also, what is the output of:

docker run -it --rm --name=pitest pihole/pihole:2022.04.1

currently working docker-compose:

services:

  pihole:
    container_name: pihole
    image: pihole/pihole@sha256:60a9127372b0f7bb4b5eb09bc95e2735eb7b237999acf4bb079eb14b0f14632e
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      - "67:67/udp"
      - "80:80/tcp"
      - "443:443/tcp"
    environment:
      TZ: 'Europe/Stockholm'
      WEBPASSWORD: 'not-my-real-password'
      # this is still needed to get pi.hole to work
      ServerIP: '192.168.211.11'
      DNSSEC: 'true'
    # this makes the name of the docker image not be a random hash. This name is recognized only in the docker host environment
    hostname: 'pi-hole-in-docker'
    # Volumes store your data between container upgrades
    volumes:
      - './pi-hole/etc-pihole/:/etc/pihole/'
      - './pi-hole/etc-dnsmasq.d/:/etc/dnsmasq.d/'
    # these are supposedly needed, otherwise you will get 127.0.0.11 problems https://github.com/pi-hole/docker-pi-hole/issues/410#issuecomment-460515706 - still doesn't work
    dns:
      - 127.0.0.1
      - 1.1.1.1
    # Recommended but not required (DHCP needs NET_ADMIN)
    #   https://github.com/pi-hole/docker-pi-hole#note-on-capabilities
    cap_add:
      - NET_ADMIN
    restart: unless-stopped

The image line used to read

 image: pihole/pihole:latest

❯ docker images pihole/pihole
REPOSITORY      TAG                   IMAGE ID       CREATED          SIZE
pihole/pihole   <none>                334d46d0f4bd   54 minutes ago   237MB
pihole/pihole   <none>                ac573d50f83a   13 hours ago     237MB
pihole/pihole   latest                036a3f19f8be   6 weeks ago      232MB
pihole/pihole   master-armhf-buster   da805bf456b6   6 months ago     334MB
pihole/pihole   master-armhf          25db6a93aa0e   20 months ago    301MB
pihole/pihole   dev                   65b1970d504f   2 years ago      324MB

(I moved the latest tag to get it to work earlier)

OK, that matches the IDs I have here, and using your above compose I get no issues loading it on an rpi 4 running bullseye.

pi@dockerpi:~/docker/playground $ uname -a
Linux dockerpi 5.10.63-v7l+ #1459 SMP Wed Oct 6 16:41:57 BST 2021 armv7l GNU/Linux
pi@dockerpi:~/docker/playground $ docker --version
Docker version 20.10.14, build a224086
pi@dockerpi:~/docker/playground $ docker images pihole/pihole:latest
REPOSITORY      TAG       IMAGE ID       CREATED             SIZE
pihole/pihole   latest    334d46d0f4bd   About an hour ago   237MB
pi@dockerpi:~/docker/playground $ cat docker-compose.yml
version: '3.3'

services:

  pihole:
    container_name: piholetest
    image: pihole/pihole:latest
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      - "67:67/udp"
      - "80:80/tcp"
      - "443:443/tcp"
    environment:
      TZ: 'Europe/Stockholm'
      WEBPASSWORD: 'not-my-real-password'
      # this is still needed to get pi.hole to work
      ServerIP: '192.168.211.11'
      DNSSEC: 'true'
    # this makes the name of the docker image not be a random hash. This name is recognized only in the docker host environment
    hostname: 'pi-hole-in-docker'
    # Volumes store your data between container upgrades
    volumes:
      - './pi-hole/etc-pihole/:/etc/pihole/'
      - './pi-hole/etc-dnsmasq.d/:/etc/dnsmasq.d/'
    # these are supposedly needed, otherwise you will get 127.0.0.11 problems https://github.com/pi-hole/docker-pi-hole/issues/410#issuecomment-460515706 - still doesn't work
    dns:
      - 127.0.0.1
      - 1.1.1.1
    # Recommended but not required (DHCP needs NET_ADMIN)
    #   https://github.com/pi-hole/docker-pi-hole#note-on-capabilities
    cap_add:
      - NET_ADMIN
    restart: unless-stopped
pi@dockerpi:~/docker/playground $ docker-compose up
Starting piholetest ... done
Attaching to piholetest
piholetest | [s6-init] making user provided files available at /var/run/s6/etc...exited 0.
piholetest | [s6-init] ensuring user provided files have correct perms...exited 0.
piholetest | [fix-attrs.d] applying ownership & permissions fixes...
piholetest | [fix-attrs.d] 01-resolver-resolv: applying...
piholetest | [fix-attrs.d] 01-resolver-resolv: exited 0.
piholetest | [fix-attrs.d] done.
piholetest | [cont-init.d] executing container initialization scripts...
piholetest | [cont-init.d] 05-changer-uid-gid.sh: executing...
piholetest | [cont-init.d] 05-changer-uid-gid.sh: exited 0.
piholetest | [cont-init.d] 20-start.sh: executing...
piholetest |  ::: Starting docker specific checks & setup for docker pihole/pihole
piholetest |
piholetest |   [i] Installing configs from /etc/.pihole...
piholetest |   [i] Existing dnsmasq.conf found... it is not a Pi-hole file, leaving alone!
  [✓] Installed /etc/dnsmasq.d/01-pihole.conf
  [✓] Installed /etc/dnsmasq.d/06-rfc6761.conf
piholetest | Existing DNS servers detected in setupVars.conf. Leaving them alone
piholetest | ::: Pre existing WEBPASSWORD found
piholetest | DNSMasq binding to default interface: eth0
piholetest | Added ENV to php:
piholetest |                    "TZ" => "Europe/Stockholm",
piholetest |                    "PIHOLE_DOCKER_TAG" => "2022.04.1",
piholetest |                    "PHP_ERROR_LOG" => "/var/log/lighttpd/error.log",
piholetest |                    "ServerIP" => "192.168.211.11",
piholetest |                    "CORS_HOSTS" => "",
piholetest |                    "VIRTUAL_HOST" => "192.168.211.11",
piholetest | Using IPv4 and IPv6
piholetest | ::: Preexisting ad list /etc/pihole/adlists.list detected ((exiting setup_blocklists early))
piholetest | https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts
piholetest | ::: Testing lighttpd config: Syntax OK
piholetest | ::: All config checks passed, cleared for startup ...
piholetest | ::: Enabling Query Logging
piholetest |   [i] Enabling logging...
  [✓] Logging has been enabled!
piholetest |  ::: Docker start setup complete
piholetest |   Checking if custom gravity.db is set in /etc/pihole/pihole-FTL.conf
piholetest |   Pi-hole version is v5.9.1 (Latest: v5.9.1)
piholetest |   AdminLTE version is v5.11 (Latest: v5.11)
piholetest |   FTL version is v5.14 (Latest: v5.14)
piholetest |   Container tag is: 2022.04.1
piholetest | [cont-init.d] 20-start.sh: exited 0.
piholetest | [cont-init.d] done.
piholetest | [services.d] starting services
piholetest | Starting crond
piholetest | Starting lighttpd
piholetest | Starting pihole-FTL (no-daemon) as pihole
piholetest | [services.d] done.

Also, if I have correctly read your debug log - you are not using Pi-hole for DHCP, you can safely remove the port mapping for port 67 and also remove the cap_add section

I moved the tag back, and did a docker-compose down/up but it did not help

REPOSITORY      TAG                   IMAGE ID       CREATED             SIZE
pihole/pihole   latest                334d46d0f4bd   About an hour ago   237MB
pihole/pihole   <none>                ac573d50f83a   13 hours ago        237MB
pihole/pihole   <none>                036a3f19f8be   6 weeks ago         232MB
pihole/pihole   master-armhf-buster   da805bf456b6   6 months ago        334MB
pihole/pihole   master-armhf          25db6a93aa0e   20 months ago       301MB
pihole/pihole   dev                   65b1970d504f   2 years ago         324MB```

❯ docker run -it --rm --name=pitest pihole/pihole:2022.04.1
Unable to find image 'pihole/pihole:2022.04.1' locally
2022.04.1: Pulling from pihole/pihole
Digest: sha256:91fbceda5406e63ffdfb807324d48d42f0bee8041396fbfd581067af303424ea
Status: Downloaded newer image for pihole/pihole:2022.04.1
[s6-init] making user provided files available at /var/run/s6/etc...exited 0.
[s6-init] ensuring user provided files have correct perms...exited 0.
[fix-attrs.d] applying ownership & permissions fixes...
[fix-attrs.d] 01-resolver-resolv: applying...
[fix-attrs.d] 01-resolver-resolv: exited 0.
[fix-attrs.d] done.
[cont-init.d] executing container initialization scripts...
[cont-init.d] 05-changer-uid-gid.sh: executing...
[cont-init.d] 05-changer-uid-gid.sh: exited 0.
[cont-init.d] 20-start.sh: executing...
 ::: Starting docker specific checks & setup for docker pihole/pihole
Assigning random password: 6vVbdYe8

  [i] Installing configs from /etc/.pihole...
  [i] Existing dnsmasq.conf found... it is not a Pi-hole file, leaving alone!
  [✓] Installed /etc/dnsmasq.d/01-pihole.conf
  [✓] Installed /etc/dnsmasq.d/06-rfc6761.conf
Existing DNS servers detected in setupVars.conf. Leaving them alone
  [✓] New password set
DNSMasq binding to default interface: eth0
Added ENV to php:
                        "TZ" => "",
                        "PIHOLE_DOCKER_TAG" => "2022.04.1",
                        "PHP_ERROR_LOG" => "/var/log/lighttpd/error.log",
                        "ServerIP" => "0.0.0.0",
                        "CORS_HOSTS" => "",
                        "VIRTUAL_HOST" => "0.0.0.0",
Using IPv4 and IPv6
::: setup_blocklists now setting default blocklists up:
::: TIP: Use a docker volume for /etc/pihole/adlists.list if you want to customize for first boot
::: Blocklists (/etc/pihole/adlists.list) now set to:
https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts
::: Testing lighttpd config: Syntax OK
::: All config checks passed, cleared for startup ...
::: Enabling Query Logging
  [i] Enabling logging...
  [✓] Restarting DNS server
  [✓] Logging has been enabled!
 ::: Docker start setup complete
  Checking if custom gravity.db is set in /etc/pihole/pihole-FTL.conf
  Pi-hole version is v5.9.1 (Latest: v5.9.1)
  AdminLTE version is v5.11 (Latest: v5.11)
  FTL version is v5.14 (Latest: v5.14)
  Container tag is: 2022.04.1
[cont-init.d] 20-start.sh: exited 0.
[cont-init.d] done.
[services.d] starting services
Starting lighttpd
Starting pihole-FTL (no-daemon) as pihole
Starting crond
[services.d] done.

So looks like the image works on your hardware... what next? 🤔

What is the output of docker info? (not that I'm 100% I'll be able to understand!)

❯ docker info
Client:
 Context:    default
 Debug Mode: false
 Plugins:
  app: Docker App (Docker Inc., v0.9.1-beta3)
  buildx: Docker Buildx (Docker Inc., v0.8.1-docker)

Server:
 Containers: 3
  Running: 3
  Paused: 0
  Stopped: 0
 Images: 13
 Server Version: 20.10.14
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 1
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runtime.v1.linux runc io.containerd.runc.v2
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 3df54a852345ae127d1fa3092b95168e4a88e2f8
 runc version: v1.0.3-0-gf46b6ba
 init version: de40ad0
 Security Options:
  seccomp
   Profile: default
 Kernel Version: 5.10.103-v8+
 Operating System: Raspbian GNU/Linux 10 (buster)
 OSType: linux
 Architecture: aarch64
 CPUs: 4
 Total Memory: 3.706GiB
 Name: raspberrypi4docker
 ID: GHLE:KSE6:UXZK:PQM4:KU3Q:MKCL:4F7B:XDYQ:4F75:YT57:2OYF:XW2X
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: true
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

WARNING: No memory limit support
WARNING: No swap limit support
WARNING: No kernel memory TCP limit support
WARNING: No oom kill disable support

I don't know if it's relevant, but there was an issue with the arm64 / aarch64 architectures a while back https://github.com/pi-hole/docker-pi-hole/issues/587#issuecomment-594251857 Is the fix applied to all architectures?

As a last ditch workaround, can you add DNSMASQ_USER: 'root' to your environment and see if that makes a difference, please?

A couple of other questions that come to mind:

• Are you seeing this issue because you are on aarch64?
• Are you seeing this issue because you are on buster (how painful would it be to upgrade to bullseye? Is there even an aarch64 bullseye raspbian image?)

I don't know if it's relevant, but there was an issue with the arm64 / aarch64 architectures a while back #587 (comment)

Possibly not - we have since switched to using buildx for the multiarch images rather than our homebrew method

Dug out a Pi3 from the back of a drawer. Going to try 64bit bullseye...

Adding DNSMASQ_USER: 'root' to environment: made no difference.

Last I checked you couldn't do major upgrades on Raspbian, so going to bullseye would be a full reinstall of the OS, so that would be a hassle. I could do it I guess, but I don't have the time in the next few weeks.

Dug out a Pi3 from the back of a drawer. Going to try 64bit bullseye...

Seems to work fine with the same compose file outlined above.

I had to jump through some hoops and use compose v2 as installing docker-compose 1.x was not working via the normal method (installed Docker 20.10.14 via the convenience script) but I cannot see how that would affect things...

Comparing the image IDs / digests, things are different (double checked the created date on each as the CREATED column looked off)

64 bit pi 3:

pi@raspberrypi64:~ $ docker images pihole/pihole --digests
REPOSITORY      TAG         DIGEST                                                                    IMAGE ID       CREATED       SIZE
pihole/pihole   2022.04.1   sha256:91fbceda5406e63ffdfb807324d48d42f0bee8041396fbfd581067af303424ea   71625e6cc03b   2 hours ago   295MB
pihole/pihole   latest      sha256:91fbceda5406e63ffdfb807324d48d42f0bee8041396fbfd581067af303424ea   71625e6cc03b   2 hours ago   295MB

pi@raspberrypi64:~ $ docker inspect -f '{{ .Created }}' pihole/pihole:latest
2022-04-02T11:04:59.160847745Z

And on my 32 bit Pi4:

pi@dockerpi:~/docker/playground $ docker images pihole/pihole --digests
REPOSITORY      TAG         DIGEST                                                                    IMAGE ID       CREATED        SIZE
pihole/pihole   2022.04.1   sha256:91fbceda5406e63ffdfb807324d48d42f0bee8041396fbfd581067af303424ea   334d46d0f4bd   3 hours ago    237MB
pihole/pihole   latest      sha256:91fbceda5406e63ffdfb807324d48d42f0bee8041396fbfd581067af303424ea   334d46d0f4bd   3 hours ago    237MB

pi@dockerpi:~/docker/playground $ docker inspect -f '{{ .Created }}' pihole/pihole:latest
2022-04-02T11:04:59.161872753Z

What is the output of docker images pihole/pihole --digests on yours? I note your image IDs are actually the same as my 32 bit image ids.. which is probably where the problem is. Note the size differences between my two devices, too

AFAIK - 64 bit Raspbian is still in beta (at least, it definitely was when it was based on buster!!!) which could explain the oddities you are seeing, where others are reporting the issues are fixed. The beta has only just recently been opened to a wider audience according to this blog:

https://www.raspberrypi.com/news/raspberry-pi-os-64-bit/

My suggestion for now is to try bullseye (either the 64 bit image or 32 bit, up to you - but if it doesn't work on the former, try the latter) and go from there... I'll hold this issue open until you can try this...

Just realised you said you reverted. I'm not able to match those digest hashes to anything on docker hub? Where are you getting that from?

Comparing the image IDs / digests, things are different (double checked the created date on each as the CREATED column looked off)

FYI you can use this to get the digest corresponding to dockerhub:

docker image inspect image:tag --format '{{json .RepoDigests}}'

❯ docker images pihole/pihole --digests
REPOSITORY      TAG                   DIGEST                                                                    IMAGE ID       CREATED         SIZE
pihole/pihole   2022.04.1             sha256:91fbceda5406e63ffdfb807324d48d42f0bee8041396fbfd581067af303424ea   334d46d0f4bd   7 hours ago     237MB
pihole/pihole   latest                sha256:91fbceda5406e63ffdfb807324d48d42f0bee8041396fbfd581067af303424ea   334d46d0f4bd   7 hours ago     237MB
pihole/pihole   <none>                sha256:7ca50487539eb222c2e989ceba361e8b733bbd51ec8c01db56f7bd81b5ae370b   ac573d50f83a   19 hours ago    237MB
pihole/pihole   <none>                sha256:60a9127372b0f7bb4b5eb09bc95e2735eb7b237999acf4bb079eb14b0f14632e   036a3f19f8be   6 weeks ago     232MB
pihole/pihole   master-armhf-buster   sha256:00d1ccf368231c70f27340c40ab7b102c2543082eeacf7bf6605da2ed08cba70   da805bf456b6   6 months ago    334MB
pihole/pihole   master-armhf          sha256:2544519d2b9bf58db553dd4299d2992d5f65ed4d0627f096f09aacadf8f48f5b   25db6a93aa0e   20 months ago   301MB
pihole/pihole   dev                   sha256:3a4c8cc914b3e39ed9761bfdd51f8f947e4c75073493aa31d183a1be9f808b59   65b1970d504f   2 years ago     324MB

Working on a new image that should detect NET_ADMIN and prevent DHCP from being activated. Also will allow non-DHCP to run without NET_ADMIN.

Please check 2022.04.2beta when the image is pushed to the repositories. Should be within 10 minutes of now.

pihole/pihole:2022.04.2beta image was already pushed.

still getting

sudo: unable to get time of day: Operation not permitted
sudo: error initializing audit plugin sudoers_audit

I'm not sure how we can proceed on that, we don't call sudo in any capacity in the image.

It is happening when accessing the web interface

It looks like your system isn't allowing date to be called.

Since this is an issue that is unrelated to this thread, please open a new issue.

I found this thread by searching for sudo: unable to get time of day: Operation not permitted https://github.com/pi-hole/docker-pi-hole/issues/1043#issuecomment-1086622885

Okay, are you using Raspbian 64bit Buster?

pihole/pihole:2022.02.1 is working

Linux kellerpi 5.10.103-v7l+ #1529 SMP Tue Mar 8 12:24:00 GMT 2022 armv7l GNU/Linux

Okay, are you using Raspbian 64bit Buster?

What is the output of lsb_release -a?

I Am

On Sat, 2 Apr 2022 at 22:33 Dan Schaper @.***> wrote:

Okay, are you using Raspbian 64bit Buster?

— Reply to this email directly, view it on GitHub https://github.com/pi-hole/docker-pi-hole/issues/1043#issuecomment-1086717853, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANT675756RIBOZFXNBOEGDVDCVKDANCNFSM5SK2NPTA . You are receiving this because you were mentioned.Message ID: @.***>

@Mellbourn

Did you tried the new image 2022.04.2beta?

I have not tried 2022.04.2beta yet, will do that right away.

❯ lsb_release -a
No LSB modules are available.
Distributor ID: Raspbian
Description:    Raspbian GNU/Linux 10 (buster)
Release:        10
Codename:       buster

@pinguinpfleger What is the output of lsb_release -a?

lscpu

Architecture:        armv7l
Byte Order:          Little Endian
CPU(s):              4
On-line CPU(s) list: 0-3
Thread(s) per core:  1
Core(s) per socket:  4
Socket(s):           1
Vendor ID:           ARM
Model:               3
Model name:          Cortex-A72
Stepping:            r0p3
CPU max MHz:         1500,0000
CPU min MHz:         600,0000
BogoMIPS:            270.00
Flags:               half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32

lsb_release -a

No LSB modules are available.
Distributor ID:	Raspbian
Description:	Raspbian GNU/Linux 10 (buster)
Release:	10
Codename:	buster

2022.04.2beta did not work, it still threw

sudo: unable to get time of day: Operation not permitted
sudo: error initializing audit plugin sudoers_audit

2022.04.2beta did not work for me either:

pihole        | [services.d] done.
pihole        | [1965-09-06 01:17:33.000 519M] Using log file /var/log/pihole-FTL.log
pihole        | [1970-01-01 01:00:00.000 519M] ########## FTL started on pi-hole-in-docker! ##########
pihole        | [1965-09-13 16:06:40.000 519M] FTL branch: master
pihole        | [1969-12-19 05:20:44.000 519M] FTL version: v5.14
pihole        | [1969-12-19 05:20:44.000 519M] FTL commit: 52e6b95
pihole        | [1969-12-19 05:20:44.000 519M] FTL date: 2022-02-12 19:58:34 +0000
pihole        | [1969-12-19 05:20:44.000 519M] FTL user: pihole
pihole        | [1969-12-19 05:20:44.000 519M] Compiled for armv7hf (compiled on CI) using arm-linux-gnueabihf-gcc (Debian 6.3.0-18) 6.3.0 20170516
pihole        | [1969-12-19 05:19:04.000 519M] Creating mutex
pihole        | [1969-12-19 05:18:28.000 519M] Creating mutex
pihole        | [1970-05-03 01:39:29.-1184080 519M] Starting config file parsing (/etc/pihole/pihole-FTL.conf)
pihole        | [1970-01-01 01:00:00.000 519M]    SOCKET_LISTENING: only local
pihole        | [1970-01-01 01:00:00.000 519M]    AAAA_QUERY_ANALYSIS: Show AAAA queries
pihole        | [1969-12-19 05:18:52.000 519M]    MAXDBDAYS: max age for stored queries is 7 days
pihole        | [1970-01-01 01:00:00.000 519M]    RESOLVE_IPV6: Resolve IPv6 addresses
pihole        | [1970-01-01 01:00:00.000 519M]    RESOLVE_IPV4: Resolve IPv4 addresses
pihole        | [1970-01-01 01:00:00.000 519M]    DBINTERVAL: saving to DB file every minute
pihole        | [1970-01-01 01:00:00.000 519M]    DBFILE: Using /etc/pihole/pihole-FTL.db
pihole        | [1970-01-01 01:00:00.000 519M]    MAXLOGAGE: Importing up to 24.0 hours of log data
pihole        | [1969-12-19 05:18:08.42587 519M]    PRIVACYLEVEL: Set to 0
pihole        | [1969-12-19 05:18:52.000 519M]    IGNORE_LOCALHOST: Show queries from localhost
pihole        | [1932-06-24 09:46:56.-134687 519M]    BLOCKINGMODE: Null IPs for blocked domains
pihole        | [1969-12-19 05:18:52.000 519M]    ANALYZE_ONLY_A_AND_AAAA: Disabled. Analyzing all queries
pihole        | [1970-01-01 01:00:00.000 519M]    DBIMPORT: Importing history from database
pihole        | [1970-01-01 01:00:00.000 519M]    PIDFILE: Using /run/pihole-FTL.pid
pihole        | [1970-01-01 01:00:00.000 519M]    PORTFILE: Using /run/pihole-FTL.port
pihole        | [1970-01-01 01:00:00.-135675 519M]    SOCKETFILE: Using /run/pihole/FTL.sock
pihole        | [1969-12-19 05:18:12.000 519M]    SETUPVARSFILE: Using /etc/pihole/setupVars.conf
pihole        | [1970-01-01 01:00:00.000 519M]    MACVENDORDB: Using /etc/pihole/macvendor.db
pihole        | [1969-12-19 05:18:12.000 519M]    GRAVITYDB: Using /etc/pihole/gravity.db
pihole        | [1970-01-01 01:00:13.000 519M]    PARSE_ARP_CACHE: Active
pihole        | [1969-12-19 05:18:52.000 519M]    CNAME_DEEP_INSPECT: Active
pihole        | [1970-01-01 01:00:00.000 519M]    DELAY_STARTUP: No delay requested.
pihole        | [1969-12-19 05:18:52.000 519M]    BLOCK_ESNI: Enabled, blocking _esni.{blocked domain}
pihole        | [1969-12-19 05:18:52.000 519M]    NICE: Cannot change niceness to -10 (permission denied)
pihole        | [1970-01-01 01:00:00.000 519M]    MAXNETAGE: Removing IP addresses and host names from network table after 7 days
pihole        | [1969-12-19 05:18:52.000 519M]    NAMES_FROM_NETDB: Enabled, trying to get names from network database
pihole        | [1970-01-01 01:00:00.000 519M]    EDNS0_ECS: Overwrite client from ECS information
pihole        | [1970-01-01 01:00:00.000 519M]    REFRESH_HOSTNAMES: Periodically refreshing IPv4 names
pihole        | [1970-01-01 01:00:00.000 519M]    RATE_LIMIT: Rate-limiting client making more than 1000 queries in 60 seconds
pihole        | [1970-01-01 01:00:00.000 519M]    LOCAL_IPV4: Automatic interface-dependent detection of address
pihole        | [1970-01-01 01:00:00.000 519M]    LOCAL_IPV6: Automatic interface-dependent detection of address
pihole        | [1969-12-19 05:18:52.000 519M]    BLOCK_IPV4: Automatic interface-dependent detection of address
pihole        | [1969-12-19 05:18:52.000 519M]    BLOCK_IPV6: Automatic interface-dependent detection of address
pihole        | [1970-01-07 20:50:24.-1107 519M]    REPLY_ADDR4: Using IPv4 address 192.168.211.11 instead of automatically determined IP address
pihole        | [1970-01-07 20:50:24.000 519M]    SHOW_DNSSEC: Enabled, showing automatically generated DNSSEC queries
pihole        | [1969-12-19 05:18:52.000 519M]    MOZILLA_CANARY: Enabled
pihole        | [1970-01-01 01:00:00.000 519M]    PIHOLE_PTR: internal PTR generation enabled (pi.hole)
pihole        | [1970-01-03 07:36:48.000 519M]    ADDR2LINE: Enabled
pihole        | [1970-01-01 01:00:00.000 519M]    REPLY_WHEN_BUSY: Permit queries when the database is busy
pihole        | [1969-12-19 05:18:52.000 519M]    BLOCK_TTL: 2 seconds
pihole        | [1969-12-19 05:18:52.000 519M]    BLOCK_ICLOUD_PR: Enabled
pihole        | sudo: unable to get time of day: Operation not permitted
pihole        | sudo: error initializing audit plugin sudoers_audit
pihole        | sudo: unable to get time of day: Operation not permitted
pihole        | sudo: error initializing audit plugin sudoers_audit
pihole        | sudo: unable to get time of day: Operation not permitted

Ok.

We need to investigate.

If I remove this from my docker-compose.yml:

    cap_add:
      - NET_ADMIN

Then I get another error in the log:

pihole        | [1970-01-01 01:00:00.000 517M] Finished config file parsing
pihole        | [1971-04-16 10:50:16.000 517M] Database version is 12
pihole        | [1969-12-11 04:22:36.000 517M] Resizing "FTL-strings" from 40960 to (81920 * 1) == 81920 (/dev/shm: 1.1MB used, 67.1MB total, FTL uses 1.1MB)
pihole        | [1970-01-01 01:00:51.-1390062 517M] Imported 0 alias-clients
pihole        | [1970-06-12 05:54:36.-142078 517M] Database successfully initialized
pihole        | [1970-01-01 01:00:51.-140421 517M] DB warn: TIMESTAMP should be larger than 01/01/2017 but is 0
pihole        | [1970-01-01 01:00:51.-140421 517M] DB warn: TIMESTAMP should be larger than 01/01/2017 but is 0
pihole        | [1970-01-01 01:00:51.-140421 517M] DB warn: TIMESTAMP should be larger than 01/01/2017 but is 0
pihole        | [1970-01-01 01:00:51.-140421 517M] DB warn: TIMESTAMP should be larger than 01/01/2017 but is 0
pihole        | [1970-01-01 01:00:51.-140421 517M] DB warn: TIMESTAMP should be larger than 01/01/2017 but is 0

That error message is repeated very quickly, with some variations:

pihole        | [1970-01-01 01:00:51.-140421 517M] DB warn: TIMESTAMP should be larger than 01/01/2017 but is 6
pihole        | [1970-01-01 01:00:51.-140421 517M] DB warn: TIMESTAMP should be larger than 01/01/2017 but is 9
pihole        | [1970-01-01 01:00:51.-140421 517M] DB warn: TIMESTAMP should be larger than 01/01/2017 but is 13
pihole        | [1970-01-01 01:00:51.-140421 517M] DB warn: TIMESTAMP should be larger than 01/01/2017 but is 14
pihole        | [1970-01-01 01:00:51.-140421 517M] DB warn: TIMESTAMP should be larger than 01/01/2017 but is 15
pihole        | [1970-01-01 01:00:51.-140421 517M] DB warn: TIMESTAMP should be larger than 01/01/2017 but is 20
pihole        | [1970-01-01 01:00:51.-140421 517M] DB warn: TIMESTAMP should be larger than 01/01/2017 but is 20
pihole        | [1970-01-01 01:00:51.-140421 517M] DB warn: TIMESTAMP should be larger than 01/01/2017 but is 20

FYI:

❯ lscpu
Architecture:        aarch64
Byte Order:          Little Endian
CPU(s):              4
On-line CPU(s) list: 0-3
Thread(s) per core:  1
Core(s) per socket:  4
Socket(s):           1
Vendor ID:           ARM
Model:               3
Model name:          Cortex-A72
Stepping:            r0p3
CPU max MHz:         1500.0000
CPU min MHz:         600.0000
BogoMIPS:            108.00
Flags:               fp asimd evtstrm crc32 cpuid

What is the system time?

Can you run something simple like docker run -it --rm alpine sh -c "date" and see what the date is in dockerland?

This looks correct:

❯ date
Sat 02 Apr 2022 10:56:41 PM CEST

Just to clarify, is that the system date or the date reported in the alpine docker container?

❯ docker run -it --rm alpine sh -c "date"
Unable to find image 'alpine:latest' locally
latest: Pulling from library/alpine
22b1e5a07a97: Pull complete
Digest: sha256:f22945d45ee2eb4dd463ed5a431d9f04fcd80ca768bb1acf898d91ce51f7bf04
Status: Downloaded newer image for alpine:latest
Sat Dec 26 21:57:20 UTC 2105

I am in Sweden, summertime, my local time right is 22:57

But not December 2105 ;)

I think this is something to do with docker itself, not exactly sure. But since it's happening in another image I don't think its specific to our image.

And one more check please:

docker run -it --rm alpine sh -c "date -s 2022-04-02"

❯ docker run -it --rm alpine sh -c "date -s 2022-04-02"
date: can't set date: Operation not permitted
Sat Apr  2 00:00:00 UTC 2022

Okay, I really think this is down to the docker engine. Is there any way to use Bullseye to see if it is fixed there?

I have a Pi4 with Raspbian Buster 32bit and I get the same results for Alpine that you do. I'll try to image to the Bullseye release and see if I get the same response.

Unfortunately, I don't have time to upgrade to Bullseye now. I will have time in a couple of weeks.

I wanted to upgrade to bullseye anyway, maybe I can do it tomorrow or at the beginning of the next week. I will report when done. Thanx for your work and support!

This may be a long shot but have you tried to mount the hosts localtime as a workaround?

volumes:
      - /etc/localtime:/etc/localtime:ro

And remove the TZ environment variable.

I think a user suggested a workaround in issue 1042, but I haven't tested it to see if it works or is something that may break another piece of software.

But it does appear to be Buster. I've tried Bullseye and it all works okay.

So I have here largely the same problem and currently have no time to set up the entire OMV with all the stuff on bullseye again. I think that I also use 32bit OS. There are also other containers and services running on the Pi. If you can not fix this, I'll stay with pihole:2022.02.1 for now, so it currently runs without problems.

The plan is to migrate everything to an AMD architecture in the next weeks anyway, if I can manage that :D.

As said above, you could try the workaround suggested in https://github.com/pi-hole/docker-pi-hole/issues/1042.

We still suggest an upgrade to bullseye as the safest path, but you can try the workaround at your own risk.

I suggest a full backup before any attempt (even before a bullseye upgrade). Even lower risk upgrades can cause unexpected results.

This may be a long shot but have you tried to mount the hosts localtime as a workaround?

volumes:
      - /etc/localtime:/etc/localtime:ro

And remove the TZ environment variable.

Tryed, didn't fix..currently on Buster armv7.

Hi, I'm unable to run both 2022.04.1 and 2022.04.2beta given the same error above but on 32bit OS:

sudo: unable to get time of day: Operation not permitted
sudo: error initializing audit plugin sudoers_audit

while:

$ docker run -it --rm alpine sh -c "date"
Unable to find image 'alpine:latest' locally
latest: Pulling from library/alpine
22b1e5a07a97: Pull complete
Digest: sha256:f22945d45ee2eb4dd463ed5a431d9f04fcd80ca768bb1acf898d91ce51f7bf04
Status: Downloaded newer image for alpine:latest
Thu Jun 11 13:58:56 UTC 2071

These are the cap settings when running the container:

...
             --cap-add=NET_BIND_SERVICE \
             --cap-add=SYS_NICE \
             --cap-drop=NET_RAW \
...
             -e DNSMASQ_USER=pihole \
...

In the mean time I reverted to 2022.02.1 which still runs fine on my Pi4:

$ uname -a
Linux ******** 5.10.63-v7l+ #1459 SMP Wed Oct 6 16:41:57 BST 2021 armv7l GNU/Linux
$ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"
$ docker -v
Docker version 20.10.14, build a224086

TIA, Matteo

Yes, Buster is the problem. Either upgrade to Bullseye or try the user supplied link in the comments above.

Sorry, which supplied link?

On Sun, 3 Apr 2022 at 21:21, Dan Schaper @.***> wrote:

Yes, Buster is the problem. Either upgrade to Bullseye or try the user supplied link in the comments above.

— Reply to this email directly, view it on GitHub https://github.com/pi-hole/docker-pi-hole/issues/1043#issuecomment-1086931809, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANT673NOETSMDC2ZCS4QDLVDHVSDANCNFSM5SK2NPTA . You are receiving this because you were mentioned.Message ID: @.***>

Hi @dschaper and @Mellbourn,

or try the user supplied link in the comments above.

Do you mean https://github.com/pi-hole/docker-pi-hole/issues/1042#issuecomment-1086728157 i.e. https://docs.linuxserver.io/faq option 2 ?

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

Checking the results:

$ sudo apt list libseccomp2 -a
Listing... Done
libseccomp2/buster-backports,now 2.5.1-1~bpo10+1 armhf [installed]
libseccomp2/oldstable 2.3.3-4 armhf

And thanks to @julhei I'm now an happy user of 2022.04.1 🕺 .

My +1 to https://github.com/pi-hole/docker-pi-hole/issues/1042#issuecomment-1086816311.

HTH; Matteo

Yes.

This is the workaround found to work with buster host and bullseye based images.

We still suggesting to upgrade your system to bullseye as the safest path.

If you want to use buster based images, you can still use 2022.02.1

Note: 2022.02.1 (and older) are based on buster 2022.04 (and newer) are based on bullseye