monitor type ping stopped working

[ovizii]

Info
Uptime Kuma Version: 1.3.2
Using Docker?: Yes
OS: Windows (client) Docker with uptime-kuma runs on Debian 10
Browser: Chrome

I installed uptime-kuma a few days ago and setup a few monitors, most of them https and one as ping type. The ping type one stopped working yesterday evening. I know the target is up, even if I do a docker exec -ti uptime-kuma sh and do a manual ping to the same target the ping works so why does it keep failing for a full 24h inside uptime-kuma?

Also, uptimerobot reports no issues pinging this particular host.

Open for any suggestions.

[louislam]

Are there any error? You can over the bar, check docker log or event list

[ovizii]

Every single ping fails since yesterday. docker-compose down followed by docker-compose pull and docker.compose up -d does not show any errors or changes besides the failed ping.

Not sure if it will help but here you go:

docker-compose  logs -f
uptime-kuma | Monitor #6 'MzansiRace': Successful Response: 9245 ms | Interval: 60 seconds | Type: http
uptime-kuma | Monitor #19 'PBS External': Failing: PING ict.zfs.rent (63.81.90.219): 56 data bytes
uptime-kuma |
uptime-kuma | --- ict.zfs.rent ping statistics ---
uptime-kuma | 1 packets transmitted, 0 packets received, 100% packet loss
uptime-kuma |  | Type: ping
uptime-kuma | Monitor #7 'pacura.ru': Successful Response: 12581 ms | Interval: 60 seconds | Type: http

I've shortened the logs output but as you can see, the ping is failing.

docker exec -ti uptime-kuma sh
 ping ict.zfs.rent
PING ict.zfs.rent (63.81.90.219): 56 data bytes
64 bytes from 63.81.90.219: seq=0 ttl=57 time=171.232 ms
64 bytes from 63.81.90.219: seq=1 ttl=57 time=171.437 ms
64 bytes from 63.81.90.219: seq=2 ttl=57 time=171.664 ms
^C
--- ict.zfs.rent ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 171.232/171.444/171.664 ms

from my docker host:

ping ict.zfs.rent
PING ict.zfs.rent (63.81.90.219) 56(84) bytes of data.
64 bytes from ict.zfs.rent (63.81.90.219): icmp_seq=1 ttl=58 time=171 ms
64 bytes from ict.zfs.rent (63.81.90.219): icmp_seq=2 ttl=58 time=171 ms
64 bytes from ict.zfs.rent (63.81.90.219): icmp_seq=3 ttl=58 time=171 ms
64 bytes from ict.zfs.rent (63.81.90.219): icmp_seq=4 ttl=58 time=171 ms
^C
--- ict.zfs.rent ping statistics ---
5 packets transmitted, 4 received, 20% packet loss, time 8ms
rtt min/avg/max/mdev = 171.257/171.322/171.406/0.418 ms

[louislam]

Really strange, as Uptime-kuma is also using the builtin "ping"

Could you also try this? This is how Uptime Kuma executes the ping command

ping -n -w 2 -c 1 ict.zfs.rent

[ovizii]

Really strange, as Uptime-kuma is also using the builtin "ping"

Could you also try this? This is how Uptime Kuma executes the ping command

ping -n -w 2 -c 1 ict.zfs.rent

That does indeed fail. Need to check the manual what all those switches for the ping command do.

docker exec -ti uptime-kuma sh
/app # ping -n -w 2 -c 1 ict.zfs.rent
PING ict.zfs.rent (63.81.90.219): 56 data bytes

--- ict.zfs.rent ping statistics ---
1 packets transmitted, 0 packets received, 100% packet loss

[ovizii]

from inside your container, the '-n' option seems unknown.

ping -h
ping: unrecognized option: h
BusyBox v1.31.1 () multi-call binary.

Usage: ping [OPTIONS] HOST

Send ICMP ECHO_REQUEST packets to network hosts

        -4,-6           Force IP or IPv6 name resolution
        -c CNT          Send only CNT pings
        -s SIZE         Send SIZE data bytes in packets (default 56)
        -i SECS         Interval
        -A              Ping as soon as reply is recevied
        -t TTL          Set TTL
        -I IFACE/IP     Source interface or IP address
        -W SEC          Seconds to wait for the first response (default 10)
                        (after all -c CNT packets are sent)
        -w SEC          Seconds until ping exits (default:infinite)
                        (can exit earlier with -c CNT)
        -q              Quiet, only display output at start
                        and when finished
        -p HEXBYTE      Pattern to use for payload

I upped the seconds to wait to 5 and the ping works all of a sudden:

ping -w 5 -c 1 ict.zfs.rent
PING ict.zfs.rent (63.81.90.219): 56 data bytes
64 bytes from 63.81.90.219: seq=0 ttl=57 time=172.820 ms

--- ict.zfs.rent ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 172.820/172.820/172.820 ms

Might be internet problems at home where this NAS runs? I'm currently travelling so can'T physically check but I can access my services at home just fine.

[louislam]

Still a bit strange as your response time is within 2 seconds.

[louislam]

My guess: Your dns server is slow. It takes more than 2 seconds to resolve a domain.

You can ping the IP directly.

[chakflying]

@louislam Seems like DNS is still a huge problem. Looking around curiously I found that many people reported having DNS issues on Alpine with Docker, and some reported issues fixed by switching to Debian or other OS. Might be worth switching to Debian despite the larger image size.

[louislam]

@louislam Seems like DNS is still a huge problem. Looking around curiously I found that many people reported having DNS issues on Alpine with Docker, and some reported issues fixed by switching to Debian or other OS. Might be worth switching to Debian despite the larger image size.

Omg, that is surprising me...

@ovizii Could you please help me try again the command in your host machine? Thank you.

ping -n -w 2 -c 1 ict.zfs.rent

If your host machine is working, than I believe that Alpine Docker is having a huge problem.

[ovizii]

@ovizii Could you please help me try again the command in your host machine? Thank you.

ping -n -w 2 -c 1 ict.zfs.rent

If your host machine is working, than I believe that Alpine Docker is having a huge problem.

here you go, that seems to have instantly worked:

 ping -n -w 2 -c 1 ict.zfs.rent
PING ict.zfs.rent (63.81.90.219) 56(84) bytes of data.
64 bytes from 63.81.90.219: icmp_seq=1 ttl=58 time=173 ms

--- ict.zfs.rent ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 172.686/172.686/172.686/0.000 ms

[ovizii]

Please let me know if you think its my local system and not due to the alpine base image, I can do further tests.

[louislam]

Please let me know if you think its my local system and not due to the alpine base image, I can do further tests.

I have built a debian base image, I think it will eventually fix your problem.

uptime-kuma:1.5.2-debian

[ovizii]

Thanks, I have switched to :1.5.2-debian and everything seems fine. I guess I'll check in a few weeks later and figure out how you are handling tags.
For now I'll keep using 1.5.2-debian - maybe later you'll have a generic :debian or whatever.

[louislam]

Thanks, I have switched to :1.5.2-debian and everything seems fine. I guess I'll check in a few weeks later and figure out how you are handling tags.
For now I'll keep using 1.5.2-debian - maybe later you'll have a generic :debian or whatever.

If Debian is better for most users, I will use Debian as main tag in the future. For example:

• 1.6 (Debian)
• 1.6-alpine (Alpine)

[ovizii]

Just wanted to let you know, that I have now added fixed DNS servers to uptime-kuma's docker-compose.yml file

    dns:
      - 1.1.1.1
      - 9.9.9.9
      - 8.8.8.8

Response times have gone seriously down compared to before. Before this, the docker host used to use a locally (Docker run) DNS (adguard home).

[IIIdefconIII]

Hi is there a fix in WIP? also the docker containers here are not been read anymore.

Thanks alot! Love this tools for a lon period now

[IIIdefconIII]

the docker sock does get read ibut the statusses are offline


as while those containers are up and running smooth

[IIIdefconIII]

This is wait i get when i try to clean the database file

EDIT: Can anyone tell me how to unlock the database?
LOG:

[2023-04-14 03:14:07] [Error: insert into `heartbeat` (`down_count`, `duration`, `important`, `monitor_id`, `msg`, `ping`, `status`, `time`) values (0, 60, false, 14, '200 - OK', 51, 1, '2023-04-14 01:14:06.201') - SQLITE_BUSY: database is locked] {