uptime-kuma: [DEBIAN Base] Possibly Fix Random Down, DNS Timeout, EAGAIN, EAI_AGAIN

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

uptime-kuma:1.5.3-debian

Story:

There were some Uptime Kuma users who were facing weird connectivity problems which I cannot explain. #114 #274 #220

Recently, one of our contributions @chakflying found out that it may be related to Alpine Docker which Uptime Kuma is based on it. https://github.com/louislam/uptime-kuma/issues/294#issuecomment-909353979

https://github.com/gliderlabs/docker-alpine/issues/255

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Comments: 19 (8 by maintainers)

Most upvoted comments

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.

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.

    dns:
      - 1.1.1.1
      - 9.9.9.9
      - 8.8.8.8

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.

No more random downtimes due to mentioned errors on my end for days, seems to be fixed by this.

Currently trying the uptime-kuma:1.5.0-debian image, will report back when it has run for a while.

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.

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.

Hmm… I’m still seeing EAI_AGAIN with the Debian image. 🤔definitely doesn’t occur as often as before though.

No timeouts on my end either. It has been running for 5 days, looks like it works perfectly fine with the Debian image.

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.