[Bug] v6.1.1 /usr/local/bin/pihole: line 393: LOGFILE: readonly variable

[4-FLOSS-Free-Libre-Open-Source-Software]

This is a: Bug

Details

Running the command pihole tail results in the following error:

/usr/local/bin/pihole: line 393: LOGFILE: readonly variable

This occurs because in the current version (v6.1), the variable LOGFILE in /usr/local/bin/pihole is marked as readonly before being assigned a value? This violates shell scripting conventions and causes the script to fail?

Related Issues

• I have searched this repository/Pi-hole forums for existing issues and pull requests that look similar
  Discourse thread on this bug

How to reproduce the issue

1. Environment data

• Operating System: Debian 12 Bookworm
• Hardware: x86_64 PC
• Kernel Architecture: x86_64
• Docker Install Info and version:
  • Software source: official docker-ce
  • Supplimentary Software: none
• Hardware architecture: x86_64

2. docker-compose.yml contents:

version: "3"

services:
  pihole:
  container_name: pihole
  image: pihole/pihole
  network_mode: host
  cap_add:
    - NET_ADMIN # In this case, the `NET_ADMIN` capability is added, which allows the container to perform various network-related tasks.
    - NET_BIND_SERVICE # Allows FTLDNS binding to TCP/UDP sockets below 1024 (specifically DNS service on port 53)
    - NET_RAW # use raw and packet sockets (needed for handling DHCPv6 requests, and verifying that an IP is not in use before leasing it)
    # - NET_ADMIN # modify routing tables and other network-related operations (in particular inserting an entry in the neighbor table to answer DHCP requests using unicast packets)
    - SYS_NICE # FTL sets itself as an important process to get some more processing time if the latter is running low
    - CHOWN # we need to be able to change ownership of log files and databases in case FTL is started as a different user than pihole
    - NET_BROADCAST # DHCP broadcast Make socket broadcasts, and listen to multicasts.
    - CAP_SYS_TIME # WARNING Insufficient permissions to set system time (CAP_SYS_TIME required), NTP client not available
    - CAP_SETGID
    - CAP_SETUID
  restart: unless-stopped
  # 	RAM shortage (/dev/shm) ahead: 99% used
  shm_size: "2G"
  environment:
    FTLCONF_debug_caps: true
    PIHOLE_UID: 999
    PIHOLE_GID: 999
    FTLCONF_ntp_ipv4_active: false
    FTLCONF_ntp_ipv6_active: false
    FTLCONF_ntp_sync_active: false
    FTLCONF_dns_cache_optimizer: '0'
    FTLCONF_dhcp_rapidCommit: true
    FTLCONF_webserver_interface_theme: "default-auto"
    FTLCONF_webserver_interface_boxed: false
    PIHOLE_PTR: "HOSTNAMEFQDN"
    FTLCONF_misc_nice: "-1"
 volumes:
    - type: bind
      source: /etc/timezone
      target: /etc/timezone
      read_only: true
    - type: bind
      source: /etc/localtime
      target: /etc/localtime
      read_only: true
    - pihole:/etc/pihole/
  cpu_shares: 2048
  extra_hosts: # workaround race condition bug https://github.com/pi-hole/docker-pi-hole/issues/1789
    - "github.com:140.82.121.3"

volumes:
  pihole:

3. Additional info: The error can be reproduced simply by running docker exec -it pihole pihole tail in a fresh container environment using the latest tag.

Installed versions (from docker exec -it pihole pihole -v):

Core version is v6.1 (Latest: v6.1.1)
  Web version is v6.2.1 (Latest: v6.2.1)
  FTL version is v6.2 (Latest: v6.2.2)


Docker Tag 2025.05.1

The bug occurs in the /usr/local/bin/pihole script at line 393. The affected code incorrectly declares the LOGFILE variable as readonly before assigning a value to it.

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

_Possible Manual fix by changing?

readonly LOGFILE="$(some_command)"

to:

LOGFILE="$(some_command)"
readonly LOGFILE

results in pihole -t working correctly again?

Root cause appears to be improper use of the readonly declaration before variable assignment in the pihole shell script?_

[PromoFaux]

Thanks - this is already fixed in the core reposiotory and will be reflected in the next tag of the Docker image.

I've been holding off on tagging docker until we get FTL 6.2.3 out, which will resolve some major bugs.

Should be... Soon™