Pi Hole, can't update lists

I've used Pi Hole for the last two months without problems. Last week I updated to Pi-hole Version v3.0.1 Web Interface Version v3.0.1 FTL Version v2.7.3 using the curl install command. Since then the Pi hole shows 0 domains blocked. So I tried to update the list of ad serving domains via tools > update list. But that does not work:

::: Neutrino emissions detected...
:::
::: Pulling source lists into range... done!
:::
::: Getting raw.githubusercontent.com list... done
::: Status: Status
::: Download failed and no cached list available (list will not be considered)
::: Getting mirror1.malwaredomains.com list... done
::: Status: Status
::: Download failed and no cached list available (list will not be considered)
::: Getting sysctl.org list... done
::: Status: Status
::: Download failed and no cached list available (list will not be considered)
::: Getting zeustracker.abuse.ch list... done
::: Status: Status
::: Download failed and no cached list available (list will not be considered)
::: Getting s3.amazonaws.com list... done
::: Status: Status
::: Download failed and no cached list available (list will not be considered)
::: Getting s3.amazonaws.com list... done
::: Status: Status
::: Download failed and no cached list available (list will not be considered)
::: Getting hosts-file.net list... done
::: Status: Status
::: Download failed and no cached list available (list will not be considered)
::: Getting adaway.org list... done
::: Status: Status
::: Download failed and no cached list available (list will not be considered)
:::
::: Aggregating list of domains... done!
::: Formatting list of domains to remove comments.... done!
::: 0 domains being pulled in by gravity...
::: Removing duplicate domains.... done!
::: 0 unique domains trapped in the event horizon.
:::
::: Adding adlist sources to the whitelist... done!
::: Whitelisting 7 domains... done!
::: Nothing to blacklist!
::: No wildcards used!
::: Formatting domains into a HOSTS file... done!
:::
::: Cleaning up un-needed files... done!
:::
::: Refresh lists in dnsmasq... done!
::: DNS service is running
::: Pi-hole blocking is Enabled

So I tried to uninstall using pihole -uninstall. Rebooted the Pi and tried the curl install script again. But it still gives me the same error message.

Any idea to what I am doing wrong?

Run pihole -d for a debug token.

::: ---=== Your debug token is : Use netcat. Please make a note of it. ===---
::: Contact the Pi-hole team with your token for assistance.
::: Thank you.
::: A local copy of the Debug log can be found at : /var/log/pihole_debug.log

Also a hole lotta:
/opt/pihole/piholeDebug.sh: line 51: 3: Bad file descriptor

Try manually uploading that file somewhere, as it seems it was unable to upload by itself.

Sadly, the pihole_debug is empty.

These errors might be the results of file system errors.
You cant run the filesystem checker "fsck" on a mounted partition on a running system.
Below one will force to filesystem checker to be run at boot before they get mounted:

sudo touch /forcefsck

sudo reboot

Not sure if anything is logged as this check is run before any of the block devices gets mounted like "/" or "/boot".
Keep an eye on the screen!

And if you experience lots of weird filesystem issues, it might be that the SD card is broken but in most cases,
this is caused by an inadequate power source for the Pi (>= 2 Ampere) or poor quality cables (USB) or too many USB devices connected to Pi.

I don't think that is the issue. Saw nothing on the screen after both commands. The Pi is powered by a 2A 5V micro usb charger, that is charging a powerbank as a UPS for the Pi (passthrough). Also Domoticz is running fine on the same Pi.

Just a guess.
If you search that bad descripter message, it could only mean FS corruption or a mistake in the code.
As thousends use Pi-Hole without that error, the later is unlikely but still ...

And I've seen many of strange issues being caused by wrong power so I thought I point it out again.

EDIT: Is your SD card a Samsung one ?
I've read some issues with newer Samsung cards not behaving on a Pi.

Hmmm it is the code:

root@noads:~# echo "${@}" >&3
-su: 3: Bad file descriptor

Fun fact, did a pihole uninstall. Then forced the Pi to power down, (pulled the cable). Booted the Pi with a display attached, saw nothing abnormal. Domoticz still worked. Then used putty to give it the install script again and we are blazing without ads again!

I was already looking up how many times that "log_write" function was called upon but seems I dont have to :smiley:

log_write() {
    echo "${@}" >&3
}

It is still a mystery to me why the Pi-Hole did not work. I just did the same thing again and now it works...

Such mysteries!

That section of the debug code is part of the privacy enhancements that we're working on. The script opens a file in the /tmp directory with a random name and the immediately deletes the file. We can then access the file by the file handle, but the file itself is not accessible outside of the script. In this way we don't leave random files in the /tmp directory with information that may be sensitive in nature and the owner may not want left around.

The error would indicate that the temp file was deleted, and thus the file handle was no longer valid. Possible if the /tmp directory was a stored in ram and the ram was flushed or the directory rotated.

2 Likes

Smart one.
I did not know that was possible with the file pointer.
Wonder how/if this works with COW filesystems like BTRFS.

Should, the COW system shouldn't interfere with the creation and usage of the file, here's the snippet of how the file is set up....

# Create temporary file for log
TEMPLOG=$(mktemp /tmp/pihole_temp.XXXXXX)
# Open handle 3 for templog
exec 3>"$TEMPLOG"
# Delete templog, but allow for addressing via file handle.
rm "$TEMPLOG"

But after you remove the file, isnt it possible that another process is going to write to the same address space and corrupting/conflicting with possibly debug still reading/writing to that space ?

EDIT: debug needs to hurry :wink:

No, the file is deleted, but it's still in the filesystem, just not accessible, as long as there is an open handle to the file it's still technically there, just not viewable. You could access the file still if you found the PID of the debug run, listed it's file descriptors and found handle 3 (or 4, we use two files, in this way). Once the debug script is finished and exits, the handles close and then the temporary file is removed from the file table.

and

Weird to grasp the concept.
But as with anything in Linux, nothing is impossible :wink: