Closed geerlingguy closed 2 years ago
Also—to immediately regenerate the file you can run sudo resolvconf -u
(this could be a handler in the playbook maybe, triggered if the file is changed).
Another symptom seems to be "DNS temporarily unavailable" when attempting to update gravity from the Pi-Hole GUI. Changing /etc/resolve.conf in the container from 127.0.0.11 to 127.0.0.1 seemed to fix it.
I'm running only the internet monitoring part, and with the uptime domain checker thingy I get this error too. Sometimes it does work, and sometimes it fetches with this error (and then the domain gets a red bar).
Logs for the probe:
ts=2021-09-16T18:03:59.176311679Z caller=main.go:320 module=http_2xx target=https://mydomain.com/ level=info msg="Beginning probe" probe=http timeout_seconds=9.5
ts=2021-09-16T18:03:59.176499841Z caller=http.go:335 module=http_2xx target=https://mydomain.com/ level=info msg="Resolving target address" ip_protocol=ip4
ts=2021-09-16T18:03:59.178395177Z caller=http.go:335 module=http_2xx target=https://mydomain.com/ level=info msg="Resolved target address" ip=yes
ts=2021-09-16T18:03:59.178497458Z caller=client.go:251 module=http_2xx target=https://mydomain.com/ level=info msg="Making HTTP request" url=https://yes host=mydomain.com
ts=2021-09-16T18:04:08.678848323Z caller=main.go:130 module=http_2xx target=https://mydomain.com/ level=error msg="Error for HTTP request" err="Get \"https://yes/\": context deadline exceeded"
ts=2021-09-16T18:04:08.678926164Z caller=main.go:130 module=http_2xx target=https://mydomain.com/ level=info msg="Response timings for roundtrip" roundtrip=0 start=2021-09-16T18:03:59.178579739Z dnsDone=2021-09-16T18:03:59.178579739Z connectDone=2021-09-16T18:03:59.180154713Z gotConn=2021-09-16T18:03:59.189304472Z responseStart=0001-01-01T00:00:00Z tlsStart=2021-09-16T18:03:59.180208393Z tlsDone=2021-09-16T18:03:59.189160831Z end=0001-01-01T00:00:00Z
ts=2021-09-16T18:04:08.678966684Z caller=main.go:320 module=http_2xx target=https://mydomain.com/ level=error msg="Probe failed" duration_seconds=9.502600404
https://stackoverflow.com/questions/49817558/context-deadline-exceeded-prometheus changing scrape timeout to 30 seconds fixed it
Ran into this same issue... uncommenting name_servers=127.0.0.1
in Inside /etc/resolvconf.conf
fixed the problem for me.
+1 to adding this change to the playbook
how do i fix this if im running networkmanager and resolvconf isnt installed?
+1 I had this same problem with the internet-pi
setup, and was able to get it resolved by just uncommenting name_server=127.0.0.1
in /etc/resolvconf.conf
and then rebooting. Maybe a reboot wasn't needed, but it didn't start working right away, so I just rebooted the pi to be sure.
why is this change not in the ansible repo? Every time you provision a Pi you have to do this one by hand ...
Guess this is related to this issue, but then it also somehow behaves differently.
Upon trying to get GRAFANA running, I get the restart loop as described by many others. Starting the docker-compose up -d --no-deps
from ~/internet-monitoring
it seems to create the front-tier network, but the container internet-monitoring_grafana_1
exits with the ERROR message, that the network {network-id} was not found:
ERROR: for internet-monitoring_grafana_1 Cannot start service grafana: network 153e8159ca612973863d2a43e4603c236481cade36b39129d1e57ab1ba1ce8e9 not found
The /etc/resolv.conf looks like this:
# Generated by resolvconf
nameserver 127.0.0.1
And the /etc/resolvconf.conf looks like this:
# Configuration for resolvconf(8)
# See resolvconf.conf(5) for details
resolv_conf=/etc/resolv.conf
# If you run a local name server, you should uncomment the below line and
# configure your subscribers configuration files below.
name_servers=127.0.0.1
# Mirror the Debian package defaults for the below resolvers
# so that resolvconf integrates seemlessly.
dnsmasq_resolv=/var/run/dnsmasq/resolv.conf
pdnsd_conf=/etc/pdnsd.conf
unbound_conf=/etc/unbound/unbound.conf.d/resolvconf_resolvers.conf
Finally I checked for the available networks with docker network ls
and the {network-id} that internet-monitoring_front-tier seems to represent is not listed there.
Any ideas from you helpful and experienced docker-folks out there?
Any ideas from you helpful and experienced docker-folks out there?
In fact #375 worked for me as a solution.
For any future visitors: Found a solution for >= Bookworm (NetworkManager) on https://raspberrypi.stackexchange.com/questions/144937/how-to-use-public-dns-in-bookwork-64bit
That only helped, because docker used the default 8.8.8.8 dns in its /etc/resolv.conf. Real solution was https://stackoverflow.com/questions/64007727/docker-compose-internal-dns-server-127-0-0-11-connection-refused
That only helped, because docker used the default 8.8.8.8 dns in its /etc/resolv.conf. Real solution was > https://stackoverflow.com/questions/64007727/docker-compose-internal-dns-server-127-0-0-11-connection-refused
Thanks! My Grafana container finally works properly. 😃
Over in https://github.com/geerlingguy/internet-monitoring/issues/12 I was scratching my head over some new DNS issues with monitoring containers not being able to resolve DNS names—it caused Grafana to fail to launch, and all pings (once I figured out a way to get Grafana happy again) to fail.
As it turns out, Docker's built-in resolver at
127.0.0.11
was hitting the wrong backend for some reason since the Pi was getting it's LAN IP in/etc/resolv.conf
.So the fix was to uncomment the line:
Inside
/etc/resolvconf.conf
.It's probably important enough a change for compatibility that I should add a bit to the Ansible playbook to update that line in the file using
lineinfile
.