Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Portainer container Pi-Hole seems to crash every 12 odd hours #805

Closed
1 task
uhsa779 opened this issue Feb 25, 2021 · 12 comments
Closed
1 task

Portainer container Pi-Hole seems to crash every 12 odd hours #805

uhsa779 opened this issue Feb 25, 2021 · 12 comments

Comments

@uhsa779
Copy link

uhsa779 commented Feb 25, 2021

Versions

  • Pi-hole: v5.4
  • AdminLTE: v5.4
  • FTL: v5.7

Platform

  • OS and version: CentOS 7
  • Platform: Portainer-CE 2.1.1

Details

Brand new pi-hole installation on a container. It works fine for about 12 odd hours - say a full working day - and then out of the blue my network is down because there is no DNS resolution. Both times I just restarted the container and everything comes back up fine. I just wish I don't have to do this every 12 hrs.

My host server is a 16 Gb RAM, xeon proc 4 CPU. My host usage is between 40 to 50% - so I am reasoning to myself that it's not some horsepower issue here.

I read somewhere to do a pihole -r but then also read that there was some inherent bug earlier. Granted mine is a newer version but I am very new to the ways of "GitHub" and not a tech guru to just read and grasp the intricacies of how these all work. If someone can point me on how to resolve this, I would highly appreciate it.

Thank you!

Related Issues

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

How to reproduce the issue

Wait for it to happen every 12 odd hours...

  1. Environment data
  • Operating System: CentOS 7
  • Hardware:
  • Kernel Architecture:
  • Docker Install Info and version:
    • Software source:
      Client: Docker Engine - Community
      Version: 20.10.3
      API version: 1.41
      Go version: go1.13.15
      Git commit: 48d30b5
      Built: Fri Jan 29 14:34:14 2021
      OS/Arch: linux/amd64
      Context: default
      Experimental: true

Server: Docker Engine - Community
Engine:
Version: 20.10.3
API version: 1.41 (minimum version 1.12)
Go version: go1.13.15
Git commit: 46229ca
Built: Fri Jan 29 14:32:37 2021
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.4.3
GitCommit: 269548fa27e0089a8b8278fc4fc781d7f65a939b
runc:
Version: 1.0.0-rc92
GitCommit: ff819c7e9184c13b7c2607fe6c30ae19403a7aff
docker-init:
Version: 0.19.0
GitCommit: de40ad0

- Supplimentary Software: <!-- Portainer-CE 2.1.1 -->
  • Hardware architecture:
  1. docker-compose.yml contents, docker run shell command, or paste a screenshot of any UI based configuration of containers here

pihole container

  1. any additional info to help reproduce
@dschaper
Copy link
Member

Use pihole/pihole:v5.7

Don't use _amd64 or any other images that have anything on them but the version number. And don't use latest.

@uhsa779
Copy link
Author

uhsa779 commented Feb 25, 2021

Use pihole/pihole:v5.7

Done - thank you!

Don't use _amd64 or any other images that have anything on them but the version number. And don't use latest.

This "amd64" is auto-created. I removed it and created the container - i see it on the env. I stopped and deleted it, ran again only to see it back again.

@dschaper
Copy link
Member

Then you'll need to ask the Portainer maintainers to stop using that, it's not the right image/tag.

@uhsa779
Copy link
Author

uhsa779 commented Feb 25, 2021

Then you'll need to ask the Portainer maintainers to stop using that, it's not the right image/tag.

I can see that this has been going on - Issue #735

I am not really sure how to do that. I will search the internet on how to use cli to maybe create the "right" container.

There seems another issue though - when i do "pihole version" -

pihole: v5.2.4
AdminLTE: v5.4
FTL: v5.7

Is that even correct or does "pihole" need to show v5.7?

@dschaper
Copy link
Member

Is that even correct

It's correct.

@dschaper
Copy link
Member

I can see that this has been going on

That's a totally different issue.

@uhsa779
Copy link
Author

uhsa779 commented Feb 25, 2021

I can see that this has been going on

That's a totally different issue.

LOL - ok i am at the end of my "tech" brain. Is there a docker cli way I can build the "correct" container? Portainer can manage my containers - I don't need to build it via them if it's pushing the wrong image.

You will have to pretend I am not one of the super tech guys here - I can read instructions and follow it- but I am not a developer even by any remote imagination so any help is appreciated.

@dschaper
Copy link
Member

There's no need to build anything, just pull the correct image we already have created.

@dschaper
Copy link
Member

Ask the Portainer developers why they are pulling that image and then let them know that it's the wrong image.

@uhsa779
Copy link
Author

uhsa779 commented Feb 25, 2021

Ask the Portainer developers why they are pulling that image and then let them know that it's the wrong image.

Not sure if I did something but this issue shows closed - i have logged in a request for help with the portainer folks

portainer/docker-images#4

Thx.

@vnasser
Copy link

vnasser commented Feb 25, 2021

By any chance, is your CentOS host connecting to your network via WiFi and hence the Docker container is too?
Pi-hole is not really happy with Wifi (unless with super strong signal) even in Containerized setup or RPi. If yes, I would switch to ethernet and test for a couple of days.

@uhsa779
Copy link
Author

uhsa779 commented Feb 25, 2021

By any chance, is your CentOS host connecting to your network via WiFi and hence the Docker container is too?

Nope - 1g eth.
apparently i am getting "amd64" arch which shouldn't be the case?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants