[SUPPORT] pihole for unRaid - Spants repo


Recommended Posts

21 hours ago, FDM80 said:

Looks like Pi-hole v4 just came out.

https://pi-hole.net/2018/08/06/pi-hole-v4-0-released-with-ftldns-improved-blocking-modes-regex-docker-and-more/

 

It looks like they have brought diginc into the fold and have turned his work into an official docker.

I assume the unRaid template will be updated with any necessary changes.

 

The Template has been updated and pushed .... Check for updates in the next few hours.

 

Welcome to v4! 

 

(if it didn't update for you, change the repository to:     pihole/pihole:latest )

 

 

Edited by spants
  • Like 1
Link to comment
On 7/18/2018 at 8:30 AM, JustinAiken said:

After updating to the new version yesterday, I get this:

 


::: Testing DNSmasq config: ::: Testing lighttpd config: Syntax OK
::: All config checks passed, starting ...
::: Docker start setup complete
[✗] DNS resolution is currently unavailable
[cont-init.d] 20-start.sh: exited 1.
[cont-finish.d] executing container finish scripts...
[cont-finish.d] done.
[s6-finish] syncing disks.
[cont-init.d] 20-start.sh: exited 1.
[cont-finish.d] executing container finish scripts...
[cont-finish.d] done.
[s6-finish] syncing disks.
[s6-finish] sending all processes the TERM signal.
[s6-finish] sending all processes the KILL signal and exiting.

And it doesn't stay up.  DNS is set to use to 1.1.1.1

Any headway on this, i am showing the same thing

Link to comment
  • 2 weeks later...

V4.0 works great for me for awhile, then it completely stops resolving DNS.  I think it seems to be after the first reboot.  Anybody else figure out how to fix this?  If I nuke it all and reinstall - samething.  Works great for awhile, then no DNS resolution...

Link to comment
12 hours ago, mbezzo said:

V4.0 works great for me for awhile, then it completely stops resolving DNS.  I think it seems to be after the first reboot.  Anybody else figure out how to fix this?  If I nuke it all and reinstall - samething.  Works great for awhile, then no DNS resolution...

I'm in the same boat.

Link to comment

Mine keeps crapping out as well. Every time i reboot the system, pihole stops working. 

Tried turning off kvm as it reports port 53 beeing in use for some reason (my vm is a w10 client that only has usb passed to it which controls my ups). This makes the docker start at least. docker is setup to use br0 and has it's own IP. And yes the default port has been changed in regards to the webinterface. 

It starts, everything looks great, and it just commits suicide after about 5 minutes. Web interface never works, dunno what it is doing or waiting for. no logs in \var on the docker says anything usefull. Startup Log shows the following (identical to earlier post); 

::: Testing DNSmasq config: ::: Testing lighttpd config: Syntax OK
::: All config checks passed, starting ...
::: Docker start setup complete
[✗] DNS resolution is currently unavailable
[cont-init.d] 20-start.sh: exited 1.
[cont-finish.d] executing container finish scripts...
[cont-finish.d] done.
[s6-finish] syncing disks.
[cont-init.d] 20-start.sh: exited 1.
[cont-finish.d] executing container finish scripts...
[cont-finish.d] done.
[s6-finish] syncing disks.
[s6-finish] sending all processes the TERM signal.
[s6-finish] sending all processes the KILL signal and exiting.

Tried reinstalling from my local template, same result. 

Purging and reinstalling from scratch seems to work. 

It is starting to get quite annoying having to reinstall this each time i reboot my system 😛(it's usually on 24/7 but having some disk issues and have had to reboot the server a few times lately). 

 

Going for a VM with pihole for the time being, just providing feedback, will ping back. 

 

Update:

 

Not really that different it seems.

Had to remove a disk physically from array (sending it for warranty replacement). 

This time the pihole FTL service stopped working and would not start again after the reboot. "Adress already in use" , seems the fix was to remove 'dns=dnsmasq' from /etc/NetworkManager/NetworkManager.conf 

Then; systemctl reload NetworkManager followed by systemctl restart pihole-FTL.service 

This fixed my issue (for now at least). - I did change the IP for the VM but I highly doubt this matters, I am certain the modification of the conf file fixed it. 

 

So, in conclusion. Is dnsmasq on unraid screwing up something in relation to the docker version ? 

Edited by Abnorm
Link to comment
On 8/23/2018 at 8:12 AM, mbezzo said:

Submitted this if others with the issue want to add on/comment: https://github.com/pi-hole/docker-pi-hole/issues/321

 

I noticed something that could be the cause of your issue, in the Docker run command you posted in your GitHub issue that you've set the variable: 'INTERFACE'='br0'

I believe this variable needs to refer to the name of the container's internal interface which is 'eth0', rather than the name of UnRaid network interface the container is running on which in your case is 'br0'

 

@bonienl posted instructions a few pages back on how to re-configure this

 

If you haven't tried this already it might be worth giving this a shot

  • Upvote 1
Link to comment
On 8/31/2018 at 5:38 PM, Tyler said:

I noticed something that could be the cause of your issue, in the Docker run command you posted in your GitHub issue that you've set the variable: 'INTERFACE'='br0'

I believe this variable needs to refer to the name of the container's internal interface which is 'eth0', rather than the name of UnRaid network interface the container is running on which in your case is 'br0'

 

@bonienl posted instructions a few pages back on how to re-configure this

 

If you haven't tried this already it might be worth giving this a shot

THANKS @Tyler! This did the trick for me.  I can't quite remember if I changed that to br0 or not - seems like that was default... Appreciate the reply! 

Link to comment

Ok, at the suggestion of @SteelzFinest i went back and reread the thread.

This is day 5 of my deep dive and I have finally tracked down the combo to keep the container running.

 

TL;DR:

Unraid Template upgraded from 3.0 and was causing problems.

Change template VARIABLE (Key 7) from: br0 to eth0

Add Container Variables: PUID=99 PGID=100

 

_________________________

 

Chief Complaint:

After upgrading from Pihole 3.x to latest, the web service is inaccessible and the container stops without restarting.

The container stays running for approx 90 seconds. Problem persist even after a fresh rebuild, not using the previous docker image or anything saved in a docker volume.

 

Scope:

unraid pihole container running DNS only. DHCP is handled by an asus router.

 

Observed symptoms:

- Permission issues from the container with the docker volume

- Inside the container, br0 is missing.

- expected behavior with same physical network config is drastically different with Pihole 4.x (latest). Specifically, the previous config would resolve same network hostnames, even though "Never forward non-FQDNs" and "Never forward reverse lookups for private IP ranges" were both check on the previous version.

- web server not responding

- container crashes and fails to restart

 

Example crash log:

Starting pihole-FTL (no-daemon)
Starting crond
Starting lighttpd
[services.d] done.
/opt/pihole/gravity.sh: line 637: /etc/pihole/list.preEventHorizon: No such file or directory
Stopping pihole-FTL
Starting pihole-FTL (no-daemon)
Stopping pihole-FTL
Starting pihole-FTL (no-daemon)
/opt/pihole/gravity.sh: line 637: /etc/pihole/list.preEventHorizon: No such file or directory
comm: /etc/pihole/list.preEventHorizon: No such file or directory
Stopping pihole-FTL
Starting pihole-FTL (no-daemon)
Stopping pihole-FTL
Starting pihole-FTL (no-daemon)
comm: file 1 is not in sorted order
comm: file 1 is not in sorted order
Stopping pihole-FTL
Starting pihole-FTL (no-daemon)

 

Detailed Workaround:

With the template interface set to br0, I managed to restart the webservice by entering the containers and running the following:

docker exec -it pihole bash

Then, changing the default resolver config away from the default of 127.0.0.11 by running the following:

cd /etc \
&& find ${BASIN_SPIDER_CONFIG_PATH} -type f -name "resolv.conf" | xargs -L1 bash -c 'sed "s/nameserver 127.0.0.11/nameserver 127.0.0.1/g" $1 > /tmp/.intermediate-file-2431; cp /tmp/.intermediate-file-2431 $1;' -- \
&& cat /etc/resolv.conf

Since the container doesn't have any editors and running sed by itself revealed a file lock of some variety, I scrapped the above together based on some stack exchange suggestions.

 

The container now stayed alive long enough that I was able to dig into the networking issue.

My unraid template was assigning br0, which I eventually found was missing from inside the container.

 

Changing the template Key 7 (Container Variable: Interface) to eth0 revealed through testing that the need to rename the default resolver was no longer needed. But the container was still crashing.

 

NOTE: The Network Type is still Custom: br0 for me.

 

Adding the respective container variables to the template appears to have solved the trick.

Add Container Variables: PUID=99 PGID=100  See attached screencap.

 

 

If this works for anyone else, let me know and I will share it on github.

 

- semtex

 

 

 

 

 

pihole PIDUID.PNG

Edited by semtex41
Corrected spelling and added for clarity.
Link to comment
8 hours ago, semtex41 said:

Ok, at the suggestion of @SteelzFinest i went back and reread the thread.

This is day 5 of my deep dive and I have finally tracked down the combo to keep the container running.

 

If this works for anyone else, let me know and I will share it on github.

 

- semtex

 

 

Hi Semtex41

 

Thanks for the suggestions which I have now put into the master template (UID and change to eth0). I guess that many of us were not having issues due to running it before and manual tweaks etc.

 

The changes to the template should update shortly.

Link to comment
  • 2 weeks later...

I don't know why but this container is crashing at completely random intervals. Sometimes after just 5 minutes of being started, sometimes after 5 days. There's noting in the log except that the KILL signal was sent even though nothing should be stopping the docker container. If it's some kind of backup application, I don't know why this is happening because then it should happen to ALL my containers and yet it only happens with the PiHole docker container.

 

I'll try and dump a log next time it happens but the last couple of times I checked there was absolutely no useful information at all. Just that one minute it was working and on and the next it's stopped.

 

I've also tried deleting its directory in the appdata folder and reinstalling and also using a different upstream DNS. This didn't happen 1 or 2 updates back. It may not be related at all to this container but another service on my server but I will try and get to the bottom of it.

Link to comment
9 hours ago, CowboyRedBeard said:

So based on what I've read on the git the interface needs to be changed from br0 to eth0 ??

 

Will there be an update to the community app that allows me to push button upgrade?  😃

I changed the template 2 weeks ago but it would probably (and hopefully!) not update anyones existing settings.... Note that my system works perfectly on BR0 but I understand that others have problems

 

Link to comment
7 hours ago, CowboyRedBeard said:

I guess what I'm asking is that my docker still shows 3.x and when I do a "check for updates" under docker, there's not one listed for this. Should I change the repository or something?

Hi - I'm stupid!. I made a silly mistake on the changes to the docker template. It should start working soon.

Reply here and let me know if the changes happen in the next day or so.

 

If not, change the repository to

pihole/pihole:latest

 

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.