How Do I get rid of Pihole ? I tried everything. about iotstack HOT 5 OPEN

Hi - first off, please read this project is dormant.

If I had this problem and wanted to clobber everything, here is what I would do.

I'd start by taking down my stack:

$ cd ~/IOTstack
$ docker-compose down

Then I would run docker ps. If it gave me anything more than the titles line, I would interpret that as telling me that containers were somehow running outside of what was defined in my docker-compose.yml. I would then use:

$ docker stop ID
$ docker rm -f ID

where "ID" is the value from the "CONTAINER ID" column in the docker ps output. I would keep going until docker ps only returned the titles row.

Then I would start with docker images. Anything that mentioned PiHole, I'd use:

$ docker rmi ID

where "ID" is the "IMAGE ID". If that command produced an error like this:

Error response from daemon: conflict: unable to delete 5d2168efbaca (cannot be forced) - image is being used by running container 37770d033386

I would do a docker rm ID where the ID is the one at the end of that message (in this case "37770d033386") then retry the rmi. If the rm produced an error of its own, I'd try a docker stop ID with the ID in that message. See the pattern? Keep following the errors and trying commands until something works and then retrace your steps.

Once you were sure you had removed all traces of PiHole from docker images, then run your test to see if you think PiHole is still running. If it is then that suggests you may once have installed PiHole "natively" outside of IOTstack and Docker. I'd go looking for signs of that with:

$ ps -ax | grep -i pihole

If I got hits, I'd start researching how to blow away a native install. If I didn't get hits but my tests suggested PiHole was still running, I'd have a logical contradiction and I'd start wondering whether my tests really were getting DNS services from the RPi at all and, if they truly were, whether it was actually PiHole or maybe I was running BIND?

I hope some of this helps.

For the record, I have zero trouble with PiHole - since I started running it as a container, that is. It was a right pest when i ran it natively (before Andreas' video about IOTstack). All I have ever done since I started with gcgarner/IOTstack, now SensorsIot/IOTstack, is a docker-compose pull plus docker-compose up -d. That always results in the latest and greatest.

BUT, I only run PiHole as an ad-blocker. I do not run it as a general DNS server or DHCP server. I have a local upstream DNS (BIND running on a Mac). In essence, downstream devices needing blocking services use the PiHole RPi for DNS, the PiHole either blocks or forwards. If a domain name to be resolved is either unqualified or fully qualified in my local domain, PiHole relays to the local upstream DNS, otherwise to 8.8.8.8 and its friends.

from iotstack.

@Paraphraser

thanks so much for your great help and for pointing out the status of the project. I really hope Graham Garner is well.

I have tried the above in addition to the below that I found online and it did finally eradicate pihole.

docker rm -vf $(docker ps -aq)
docker rmi -f $(docker images -aq)
docker system prune

When I previously ran the "nuclear option" from the menu, the volumes folder disappeared and I did not understand from where pihole was running. Then after running the commands the Volumes folder appeared again and i deleted its contents.

I was able to run restore and everything worked out !!

Thanks again.

from iotstack.

If you look through the docker-compose.yml you will see almost every service definition has a volumes directive, and that most of those have left hand sides beginning with ./volumes/.

under gcgarner there were several that started with ./services but I think those have all now moved to ./volumes under SensorsIot.

When you run docker-compose up -d, one of the things that happens is that the presence of all the left hand sides of all those volumes directives is checked and, if neither a file nor folder exists at that path, a folder is created with root ownership. The same thing happens inside the containers with the right hand sides. Generally, you're mapping an existing internal folder to a potentially non-existing external folder but, sometimes, you also want an internal folder created too.

Under gcgarner there were several cases where a volumes mapping was a file to a file. That worked if the external file was present but if the external file ever went walkabout, docker-compose would promptly create a folder in its place. Mapping a folder to a file is, err, "problematic" so containers would generally barf. Then the user would come along and find a root-owned folder where a file should be and that's where more than one user would declare defeat. I think all of those have gone under SensorsIot.

Anyway, that's why the volumes folder and a bunch of sub-folders re-appeared. It was docker-compose behaving normally.

On this topic, there are two classes of container: those that are well-behaved and those that aren't. See this issue for a discussion. The general idea is that you (the user) should always be able to start from a clean slate by deleting volumes or one or more named sub-folders (eg volumes/mosquitto) then "up" the stack, and each container facing a clean-slate situation should initialise with sensible defaults such that the user has a basis for moving forward. We're getting closer to that goal in SensorsIot too.

Sometimes it simply isn't feasible to force a container to be well-behaved. A good example is Zigbee2mqtt where Docker affords no mechanism for dynamic discovery of the attached dongle. You just have to figure it out. And then there are some like rtl_433 where, even when I know I'm giving the silly thing the correct devices, it still refuses to play the game... 🤬

from iotstack.

very interesting. That explains the resurrection of the volume folder. What is strange is that pihole had my historical data when I couldn't see the volume folder and also when it was recreated. I wonder where it is keeping its data.

thanks for the explanation.

from iotstack.

In that case, I'd go back to what I said in my original reply about checking whether PiHole really was running under IOTstack or had, perhaps, been installed natively at one point.

I began my own Raspberry Pi journey with a 3B+ and a native install. When I started to experiment with IOTstack I used a clean image on a different SD card. I only had a handful of custom black/whitelist entries so it was easy enough to re-enter those. But, if I had installed IOTstack on top of the original SD, I might well have found something like this. It's just a guess. Instinct suggests the native install would probably have started before the containerised version, that Docker would've moaned about the ports being in use and sent the container into a restart loop, and that I would've noticed that moaning and figured it out. But I don't know. Maybe Docker would grab the ports first and the native install would then moan into the system log where I might not have noticed it...

Can't think of any other reason. I agree - a bit of a mystery.

from iotstack.