-
-
Notifications
You must be signed in to change notification settings - Fork 332
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
Glance timing out - monitor and weather #290
Comments
Hey, thanks for reporting this! In all honesty I still have no idea why some people are seeing vastly degraded network performance from within their Docker containers. Glance's image is as basic as it gets so I like to think it's not the reason by being misconfigured in any way. As for the timeout, there's currently no way of changing it, it's something I want to add but I'm not sure what the best way of implementing it is yet. I've added a new # clone the repo's release/v0.7.0 branch
git clone -b release/v0.7.0 https://github.com/glanceapp/glance.git
cd glance
# build Glance
docker build -t local/glance -f Dockerfile .
# run the diagnose command and then remove the container, please provide the output of this command
docker run --rm local/glance diagnose This should give us some clues about whether it's bandwidth related, DNS, or limited to specific connections. |
Of course, happy to help! Here's the output:
I've also just checked how long wget takes comparing the direct IP and port and the local TLD I have set up through pihole and caddy - instantaneous for IP, 4s for TLD. This might be where the monitor issue is coming from, but presumably not for the weather api? The API call does return successfully in the container, taking 5.53 seconds. |
Thanks for providing the diagnostic info! Based on the fact that the first two requests took 34ms and 219ms and didn't involve a DNS lookup, then the subsequent 3 requests were solely a DNS lookup and took >5s, I think we can narrow this down to being a DNS issue. We can confirm that by running the same diagnose command but using Google's DNS:
This should result in all requests completing in <1s. Another thing to try is timing nslookup on your server (not inside a Docker container):
If these also ends up being slow, then there's likely something wrong with your Pi-hole's configuration. If they complete quickly, then it's likely an issue around Docker's network communicating with Pi-hole. If Pi-hole is on another server, could you also try pinging that server to ensure it's not local network related? |
Thanks for your help! Your instinct looks right - that command with google's DNS ran much quicker:
nslookups on the server are pretty instantaneous, so I'd guess it's an issue with docker's network communicating with pi-hole. Pi-hole is running bare metal on the same server as the glance container. Do you have an idea of where to look to diagnose this? |
Unfortunately this is about as far as my network debugging abilities go. You could try pinging between two random containers to see if it's a widespread Docker network issue (presumably not) or limited to containers trying to connect to Pi-hole, in which case you can start poking around its configuration for anything odd. While not ideal, as a workaround you could run Glance with |
Just installed glance and I love it - so simple, fast, and gorgeous - so thanks in advance!
I've installed via docker on a rpi5, which is also running a few other containers (HA, mostly). I've reverse proxied my services with caddy to be available locally with a local TLD.
On first install the weather widget times out with the following error:
And on adding a monitor widget for a few services those time out, too. I saw your comment in another thread about monitor to compare ping times in and outside of the container and get 8ms outside of the container and 4-8s in the container, so wondered if you had a way to adjust the timeout in glance (if this is where the error is coming from) or some tips and guidance on where to go looking for this problem?
The text was updated successfully, but these errors were encountered: