I so desperately want to bash my head into a hard surface. I cannot figure out what is causing this issue. The full error is as follows:

Error: cannot listen on the UDP port: listen udp4 :53: bind: address already in use

This is my compose file:

version: "3"
services:
  pihole:
    container_name: pihole
    image: docker.io/pihole/pihole:latest
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      - "80:80/tcp"
    environment:
      TZ: '<redacted>'
    volumes:
      - './etc-pihole:/etc/pihole'
      - './etc-dnsmasq.d:/etc/dnsmasq.d'
    restart: unless-stopped

and the result of # ss -tulpn:

Netid       State        Recv-Q       Send-Q                             Local Address:Port               Peer Address:Port       Process                                         
udp         UNCONN       0            0                    [fe80::e877:8420:5869:dbd9]:546                           *:*           users:(("NetworkManager",pid=377,fd=28))       
tcp         LISTEN       0            128                                      0.0.0.0:22                      0.0.0.0:*           users:(("sshd",pid=429,fd=3))                  
tcp         LISTEN       0            128                                         [::]:22                         [::]:*           users:(("sshd",pid=429,fd=4))        

I have looked for possible culprit services like systemd-resolved. I have tried disabling Avahi. I have looked for other potential DNS services. I have rebooted the device. I am running the container as sudo (so it has access to all ports). I am quite at a loss.

  • Raspberry Pi Model 1 Model B Rev 2
  • Raspbian (bookworm)
  • Kernel v6.6.20+rpt-rpi-v6
  • Podman v4.3.1
  • Podman Compose v1.0.3

EDIT (2024-03-14T22:13Z)

For the sake of clarity, # netstat -pna | grep 53 shows nothing on 53, and # lsof -i -P -n | grep LISTEN shows nothing listening to port 53 — the only listening service is SSH on 22, as expected.

Also, as suggested here, I tried manually binding to port 53, and I was able to without issue.

  • Climatic2469@lemmy.world
    link
    fedilink
    English
    arrow-up
    0
    ·
    edit-2
    6 months ago

    In the /etc/systemd/resolved.conf

    Set the DNSStubListener=no like below then restart the network resolvd service this should allow you to run an alternate service on port 53

    #  This file is part of systemd.
    #
    #  systemd is free software; you can redistribute it and/or modify it under the
    #  terms of the GNU Lesser General Public License as published by the Free
    #  Software Foundation; either version 2.1 of the License, or (at your option)
    #  any later version.
    #
    # Entries in this file show the compile time defaults. Local configuration
    # should be created by either modifying this file, or by creating "drop-ins" in
    # the resolved.conf.d/ subdirectory. The latter is generally recommended.
    # Defaults can be restored by simply deleting this file and all drop-ins.
    #
    # Use 'systemd-analyze cat-config systemd/resolved.conf' to display the full config.
    #
    # See resolved.conf(5) for details.
    
    [Resolve]
    # Some examples of DNS servers which may be used for DNS= and FallbackDNS=:
    # Cloudflare: 1.1.1.1#cloudflare-dns.com 1.0.0.1#cloudflare-dns.com 2606:4700:4700::1111#cloudflare-dns.com 2606:4700:4700::1001#cloudflare-dns.com
    # Google:     8.8.8.8#dns.google 8.8.4.4#dns.google 2001:4860:4860::8888#dns.google 2001:4860:4860::8844#dns.google
    # Quad9:      9.9.9.9#dns.quad9.net 149.112.112.112#dns.quad9.net 2620:fe::fe#dns.quad9.net 2620:fe::9#dns.quad9.net
    DNS=127.0.0.1
    #FallbackDNS=
    #Domains=
    #DNSSEC=no
    #DNSOverTLS=no
    #MulticastDNS=no
    #LLMNR=no
    #Cache=no-negative
    #CacheFromLocalhost=no
    DNSStubListener=no
    #DNSStubListenerExtra=
    #ReadEtcHosts=yes
    #ResolveUnicastSingleLabel=no
    
    • Telodzrum@lemmy.world
      link
      fedilink
      English
      arrow-up
      0
      ·
      6 months ago

      This is the correct solution. OP’s issue is a common one which shows up on the PiHole discussion forums regularly. I frequently forget to perform this step on new installs, too.

      • Kalcifer@sh.itjust.worksOP
        link
        fedilink
        English
        arrow-up
        0
        ·
        edit-2
        6 months ago

        This is the correct solution.

        No it isn’t. systemd-resolved is not running ­— it isn’t even installed on the device. I also already mentioned that I have looked into this fact within the body of the post.

    • Kalcifer@sh.itjust.worksOP
      link
      fedilink
      English
      arrow-up
      0
      ·
      6 months ago

      systemd-resolved is not running ­— it isn’t even installed on the device. I also already mentioned that I have looked into this fact within the body of the post.