ping property unable to reach host, host reachable via command line

[pulpocaminante]

Description

I'm able to ping a host within the docker container just fine, but the ping property isn't working. See troubleshooting:

homepage version

image:latest

Installation method

Docker

Configuration

No response

Container Logs

No response

Browser Logs

No response

Troubleshooting

I can reach host Jellyfin as such:

[root@cosmos-vm homeconfig]# docker exec -it Homepage sh
/app # ping Jellyfin
PING Jellyfin (172.16.0.227): 56 data bytes
64 bytes from 172.16.0.227: seq=0 ttl=64 time=0.046 ms
64 bytes from 172.16.0.227: seq=1 ttl=64 time=0.051 ms
64 bytes from 172.16.0.227: seq=2 ttl=64 time=0.056 ms
64 bytes from 172.16.0.227: seq=3 ttl=64 time=0.044 ms
64 bytes from 172.16.0.227: seq=4 ttl=64 time=1.307 ms
64 bytes from 172.16.0.227: seq=5 ttl=64 time=0.047 ms
^C
--- Jellyfin ping statistics ---
6 packets transmitted, 6 packets received, 0% packet loss
round-trip min/avg/max = 0.044/0.258/1.307 ms
/app # 

While this:

 - jellyfin:
      href: [redacted]
      description: media hub
      ping: Jellyfin

results in:

[glime-ai[bot]]

Thanks for posting a discussion about homepage here on GitHub. Homepage now uses a fancy new AI tool thanks to our friends at Glime, so the answer below is the AI bot's attempt to answer your question. If you feel it's sufficient you can mark the answer and close this post, otherwise feel free to leave it open of course!

Thanks for using Homepage! ❤️

---

Based on the information provided and the context from the sources, it seems that you are experiencing an issue with the ping property not showing the correct status of the service, despite being able to ping the service successfully from within the Docker container.

This could be related to a known issue with the ping functionality in the Homepage application, as indicated by the GitHub issue #2253, where adding a ping property to any service always shows "down", even if the service is actually reachable. This issue was specifically mentioned to occur with the ghcr.io/gethomepage/homepage:nightly Docker image, but it could potentially affect other versions as well.

To troubleshoot this issue further, you can try the following steps:

1. Ensure that the ping property is correctly formatted and does not contain any protocol prefixes like http://. It should be just the hostname or IP address.
2. Check if there are any updates to the Homepage application that address this issue, and if available, update to the latest version.
3. Review the Homepage container logs for any errors or warnings that might provide more insight into the problem.
4. If the issue persists, consider reporting it on the Homepage GitHub repository as a new issue or comment on an existing issue if it matches your problem.

If you need further assistance, please provide additional details such as the exact version of the Homepage application you are using, any relevant configuration details, and any error messages or logs that you can share.

This comment was generated by Glime.

[shamoon]

Pretty bad bot answer here. Ping accepts a server address, hostname or IP

[shamoon]

If you want to check a docker container you can use server/container. If you want to check a site use serverMonitor. If you want to ping a server, use ping

[arohl]

I want to use ping to determine the state of a server but when I add the ping field, all my servers say down, even though they are up and I can ping them from my desktop. I can also attach to the homepage vm and ping successfully from there. I am wondering how to debug what is going on.

[shamoon]

You said docker image, now you’re saying vm. Ping from homepage will use ping on the underlying host, the code is quite simple, we use a package called node-ping which is just a wrapper:

homepage/src/pages/api/ping.js

Line 36 in 8ff68dd

const response = await ping.probe(hostname);

[mechanarchy]

I have the same issue in v0.9.5 (eccd96a, 18 July 2024). Domain is sanitised below. services.yaml:

  - PVE:
      href: https://pve.domain.tld:8006/
      ping: pve.domain.tld

Homepage GET /api/ping?group=Group&service=PVE response body:

{
    "inputHost": "pve.domain.tld",
    "host": "bad",
    "alive": false,
    "output": "ping: bad address 'pve.domain.tld'\n",
    "time": "unknown",
    "times": [],
    "min": "unknown",
    "max": "unknown",
    "avg": "unknown",
    "stddev": "unknown",
    "packetLoss": "unknown",
    "numeric_host": "ddres"
}

However:

homepage:/homepage# ping -c1 pve.domain.tld
PING pve.domain.tld (192.168.1.2): 56 data bytes
64 bytes from 192.168.1.2: seq=0 ttl=64 time=0.037 ms

--- pve.domain.tld ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.037/0.037/0.037 ms



homepage:/homepage# docker exec -it homepage /bin/sh -c "ping -c1 pve.domain.tld"
PING pve.domain.tld (192.168.1.2): 56 data bytes
64 bytes from 192.168.1.2: seq=0 ttl=63 time=0.045 ms

--- pve.domain.tld ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.045/0.045/0.045 ms

[mechanarchy]

Whoops, nevermind. It was a typo. In case it helps anyone else diagnose their issue, this bash snippet uses the exact same function that Homepage does for its pings, so you can use this to diagnose the error.

homepage:/homepage# echo 'import("ping").then(r1 => r1.default.promise.probe("pve.domain.tld").then(r2 => console.log(r2)))' | docker exec -i homepage node
{
  inputHost: 'pve.domain.tld',
  host: 'pve.domain.tld',
  alive: true,
  output: 'PING pve.domain.tld (192.168.1.2): 56 data bytes\n' +
    '64 bytes from 192.168.1.2: seq=0 ttl=63 time=0.046 ms\n' +
    '\n' +
    '--- pve.domain.tld ping statistics ---\n' +
    '1 packets transmitted, 1 packets received, 0% packet loss\n' +
    'round-trip min/avg/max = 0.046/0.046/0.046 ms\n',
  time: 0.046,
  times: [ 0.046 ],
  min: 'unknown',
  max: 'unknown',
  avg: 'unknown',
  stddev: 'NaN',
  packetLoss: '0.000',
  numeric_host: '192.168.1.2)'
}

[github-actions[bot]]

This discussion has been automatically closed due to inactivity. See our contributing guidelines for more details.