Socket hangs up once in a while

[Miniontoby]

⚠️ Please verify that this bug has NOT been raised before.

• [X] I checked and didn't find similar issue

🛡️ Security Policy

• [X] I agree to have read this project Security Policy

Description

I recently started using Uptime Kuma for the network I am part of

But once in a while at specific websites I get an error "[🔴 Down] socket hang up"

I think this is a bug, since I am just still able to connect to the website when it happens.

And the VPS's who are running the websites are 24/7 online and accessible

👟 Reproduction steps

Add "https://oddprotocol.org/" and/or "https://bsdforall.org/" as an https monitor and come back in a day (or even shorter)

👀 Expected behavior

Only 200 response code

😓 Actual Behavior

[🔴 Down] socket hang up

and the next try it just says the 200 code

🐻 Uptime-Kuma Version

HEAD detached at 1.11.3, zo 1.11.3

💻 Operating System and Arch

Debian 5.10.84-1

🌐 Browser

Google Chrome, but it shouldn't matter since the uptime thing gives error and not the browser

🐋 Docker Version

No response

🟩 NodeJS Version

17.4.0

📝 Relevant log output

Feb  9 08:39:40 miniontoby-linux npm[41135]: Monitor #6 'BSDForAll Website': Failing: socket hang up | Interval: 60 seconds | Type: http

(...)

Feb  9 08:44:22 miniontoby-linux npm[41135]: Monitor #6 'BSDForAll Website': Successful Response: 152 ms | Interval: 60 seconds | Type: http

[louislam]

It may be a related issue of https://github.com/axios/axios/issues/2936.

Did you set http proxy?

[Miniontoby]

I don't use a http proxy. I kind of also don't even know what it actually is.

but the thing is that it sees it beeing online in the next try (automatic and manual)

[MrT3acher]

I have the same issue! I use http proxy for a https monitor. sometimes, when the website, fails to load, it hangs up. I should pause and resume the monitor to solve the problem.

thanks to @louislam, I think, it's because of http-proxy-agent here: (maybe a request timeout, solve the problem): https://github.com/louislam/uptime-kuma/blob/fb3fe17c2824e62a731270257746b9b214d17912/server/proxy.js#L117-L120

[Miniontoby]

I don't use proxy unless it is defaultly installed.

Op di 15 feb. 2022 16:37 schreef Louis Lam @.***>:

It may be a related issue of axios/axios#2936 https://github.com/axios/axios/issues/2936.

Did you set http proxy?

— Reply to this email directly, view it on GitHub https://github.com/louislam/uptime-kuma/issues/1285#issuecomment-1040422672, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALNYDYEJJAUDEXAA6OEHMMTU3JXMHANCNFSM5N5WZYWA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you authored the thread.Message ID: @.***>

[wgicio]

anyone figure this out?

[jivanyatra]

I started hitting this once I enabled geoip-based blocking on my server, even though the correct places are allowed and I can access the site without issue.

[louislam]

Since it is not reproducible, I think it is likely caused by external factors like @jivanyatra's case.

[jivanyatra]

Sorry, just wanted to add more info here in case anyone else is butting up against this, since there are so few google search results for it.

In my case, once I started adding geoip/geoip2 blocking to my NGINX config, Uptime-Kuma's checks failed with the error "[🔴 Down] socket hang up". If you tail -f /var/log/nginx/access.log you should see GET requests coming in, with the user agent marked something like "Uptime-Kuma/1.23.2".

Here's a line:

192.168.80.2 - - [01/Oct/2023:00:57:27 -0400] "GET / HTTP/1.1" 444 0 "-" "Uptime-Kuma/1.23.2"

The 444 is because that's what I have set to return for when a country is blocked. Usually when setting up geoip2 country blocking, you explicitly allow certain countries, but since the request is coming from a local (192.168.x.x) ip (in this case, from docker), it doesn't have a country code and is failing. If you default to yes, then you'll be fine.

In my case, since I'm just homelabbing, this is the relevant section of my nginx.conf (inside the http block):

        map "$geoip2_data_country_iso_code:$remote_addr" $allowed_country {
                default no;
                "~^US*" yes;
                "~*:192.168.*" yes;
        }

You can see I include the remote address in the map, and i check for internal ips and explicitly allow them. No more issues!!

You could just add something like

if ($remote_addr "~^192.168.*") {
    return 206
}

in the server block for your site's conf file, and then configure your uptime-kuma monitor to expect 206, but this wouldn't actually hit your service. It might be good enough for your needs, though.

@louislam is definitely correct in that there's likely something in everyone else's configs (apache or nginx) that's interfering with the connection.

[Miniontoby]

Uhmm, in my original (and still) case, I only monitor 10 different computers their website and domains. But ALL the webservers they run are exactly the same and they don't have a thing like geoip or what so ever.

So I don't get it. And even then, why would geoip sometimes work and the rest of the time not? That makes no sense to me.

But the problem is that I don't own all of the different computers, but what I know is that they all use the same webserver.

[CommanderStorm]

Currently, I could not replicate this issue. Can you provide us a Minimal, Reproducible Example?

[Miniontoby]

My setup exists of 31 monitors -> 12 IRC, 11 website and 8 hosts.

I could share a backup file of my setup, if wanted/needed.

[CommanderStorm]

Please read https://stackoverflow.com/help/minimal-reproducible-example

[Miniontoby]

Please read https://stackoverflow.com/help/minimal-reproducible-example

I cannot simplify uptime-kuma! So I cannot provide an example, since it is just the existing code!

The only thing 'close' to an reproducible thing, is that you will need at least 30 monitors and give it a day.

And I could provide you with the backup file of my setup.

And I have until the end of this month, cause then my vps will be shut down.

[CommanderStorm]

I cannot simplify uptime-kuma! So I cannot provide an example, since it is just the existing code!

You might start with:

• Which of the monitors is causing the issue (What is the minimum configuration you can reproduce this with?)
• How is memory/disk/cpu usage during the issue you mentioned
• is there anything in the kernel/syslog at said time

Just 30 monitors should not cause these problems, as people are running way more than that in their deployment. This is likely caused by external factors, as mentioned above.