mirror of
https://github.com/louislam/uptime-kuma.git
synced 2026-03-02 22:57:00 -05:00
[DEBIAN Base] Possibly Fix Random Down, DNS Timeout, EAGAIN, EAI_AGAIN #178
Labels
No labels
A:accessibility
A:api
A:cert-expiry
A:core
A:dashboard
A:deployment
A:documentation
A:domain expiry
A:incidents
A:maintenance
A:metrics
A:monitor
A:notifications
A:reports
A:settings
A:status-page
A:ui/ux
A:user-management
Stale
ai-slop
blocked
blocked-upstream
bug
cannot-reproduce
dependencies
discussion
duplicate
feature-request
feature-request
good first issue
hacktoberfest
help
help wanted
house keeping
invalid
invalid-format
invalid-format
question
releaseblocker 🚨
security
spam
type:enhance-existing
type:new
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/uptime-kuma#178
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @louislam on GitHub (Aug 31, 2021).
If you are experiencing such issues, it is worth to try this debian base docker image, and let me know whether it is solved. Thank you!
Docker Image
Story:
There were some Uptime Kuma users who were facing weird connectivity problems which I cannot explain.
Recently, one of our contributions @chakflying found out that it may be related to Alpine Docker which Uptime Kuma is based on it.
@CallMeTerdFerguson commented on GitHub (Aug 31, 2021):
See my comment in #275 for slightly more detail , but TLDR; switching from alpine did nothing to resolve the issue for me. I did resolve it successfully though by ensuring kuma was going directly to my DNS server by setting DNS on the container instead of requests going through the docker gateway. Does kuma's container appropriately cache and respect TTL's for DNS records?
@Oaktribe commented on GitHub (Sep 1, 2021):
Currently trying the uptime-kuma:1.5.0-debian image, will report back when it has run for a while.
@ovizii commented on GitHub (Sep 1, 2021):
Just in case someone else wants to try this, I manually added these dns servers to uptime-kuma's docker-compose.yml file and my response times have also gone down.
@Oaktribe commented on GitHub (Sep 3, 2021):
So far there has been no timeout issues for me. So it looks like it has helped? Will let it run over the weekend too and report back.
@gaby commented on GitHub (Sep 5, 2021):
From my understanding the DNS issues affecting Alpine happens if the host is using a Kernel older than 5.x. When the host is using 5.x or newer the issue doesn't happen. Commit here:
github.com/torvalds/linux@4e35c1cb94Another thing that helps with DNS issues in alpine is installing the
bind-toolspackage.@louislam commented on GitHub (Sep 5, 2021):
Interesting, but is it just a dns cli tools? Why it could affect that?👀
@gaby commented on GitHub (Sep 5, 2021):
I think you are right, it may be just be a cli tool. We use it since this comment in the Alpine Repo (https://github.com/gliderlabs/docker-alpine/issues/539#issuecomment-631471495). It helps when doing healthchecks in Kubernetes.
Another suggestion would be to update the documentation and recommend running uptime-kuma Docker container with:
docker run --dns 8.8.8.8 --dns 1.1.1.1@dbrennand commented on GitHub (Sep 5, 2021):
Hi @louislam
I have also been experiencing these issues and just started using the debian based image. I will report back in a couple of days.
@dr460nf1r3 commented on GitHub (Sep 5, 2021):
No more random downtimes due to mentioned errors on my end for days, seems to be fixed by this.
@gaby commented on GitHub (Sep 5, 2021):
Any test hostname that can be used to test this issue using the Alpine container?
@Oaktribe commented on GitHub (Sep 6, 2021):
No timeouts on my end either. It has been running for 5 days, looks like it works perfectly fine with the Debian image.
@louislam commented on GitHub (Sep 6, 2021):
Thank you for you guys' reports. Combining the reports here and the similar reports from the Internet, I am pretty sure Alpine Linux is having some kind of dns problem that they are not going to fix.
Plus, armv7 error in Alpine Linux >= 3.13, 3.14 (#41), I am going to fade out Alpine Linux in the next release.
If you are a developer in any other projects and to future me, my advice is that you should keep away from Alpine Linux. Imagine that your application need to call payment gateway API such as Paypal and it throws EAI_AGAIN randomly, that could be a disaster.
@dbrennand commented on GitHub (Sep 7, 2021):
Hmm... I'm still seeing EAI_AGAIN with the Debian image. 🤔definitely doesn't occur as often as before though.
@louislam commented on GitHub (Sep 7, 2021):
Then your local dns server is actually busy, you can config your container to use Google DNS / Cloudflare DNS directly.
https://github.com/louislam/uptime-kuma/issues/295#issuecomment-910144773
https://github.com/louislam/uptime-kuma/issues/295#issuecomment-913089357
@dbrennand commented on GitHub (Sep 9, 2021):
Hi @louislam
So you mentioning that my DNS server is busy got me thinking, I remember seeing a post on /r/selfhosted about PiHole rate-limiting queries since FTL v5.7. This might be why I'm seeing
EAI_AGAINerrors.I have just added the
RATE_LIMIT=0/0to my PiHole's/etc/pihole/pihole-FTL.confand ransudo systemctl restart pihole-FTL. Hopefully this fixes my issues. Leaving this here in case it may help someone else who is using PiHole.@louislam commented on GitHub (Sep 9, 2021):
Oh, Pihole again. Some users were using Pihole that also got the error.
I personally think that Pihole is "anti-pattern", because there is no secondary dns where you are using pihole. Pihole down, everything is down.
My recommendation is you should don't put serious things behind Pihole. Just use it for the browsing and watching Youtube.
@thespad commented on GitHub (Sep 10, 2021):
You can just run two instances on different hardware; it's no different to any other DNS resovler, you want redundancy.
As for Alpine, most of the Linuxserver fleet is using an Alpine base (mix of 3.14, 3.13, and a few older versions) and we've never encountered any widespread DNS issues - with the scale of use of our images I would have expected to get a lot of reports if it was something systemic with Alpine.
Edit: Also yikes, the image is nearly a gig with the Debian "slim" base.
@louislam commented on GitHub (Sep 10, 2021):
I actually can't reproduce the dns problem, but the fact is a few users keep reporting such problem in this repo and alpine's repo (https://github.com/gliderlabs/docker-alpine/issues/255).
I still build alpine image, you can use
1.6.0-alpine,1-alpine,alpine.@dirdante2 commented on GitHub (Jan 11, 2022):
hello
i just want to add the following info
i using dockerimage uptimekuma V 1.11.1
and dockerimage pihole Docker Tag 2021.11
i noticed a few random EAI_AGAIN errors but http website status says still UP
so everything works ... except i couldn't get smtp notification working (didn´t know why)
after updating phihole to Docker Tag 2022.01.1 and uptimekuma to 1.11.3
every monitor check that uses dns stop working completely including just http://domain status check
adding
dns:
- 1.1.1.1
- 9.9.9.9
- 8.8.8.8
to docker-compose file fixed all error including smtp notification
only if i user dns monitor and specific ask pihole i get status down error
its wired because everything else works perfectly with pihole
hope this helps
edit
just updating uptimekuma from 1.11.1 to 1.11.3
while using the old phihole container leads to the same result : uptimekuma can´t use pihole dns (I don't mean that it is uptime Kuma's fault)
@pascal-alberty-neterium commented on GitHub (Jun 27, 2025):
FYI
Still have this issue with Version: 1.23.16
I've more than 200 monitors.
Running on docker
Adding DNS solves it for me too.