search

AnalogJ / scrutiny

Hard Drive S.M.A.R.T Monitoring, Historical Trends & Real World Failure Thresholds
MIT License
4.71k stars 154 forks source link

[BUG] Docker Healthcheck broken since newest update #615

Open saschabrockel opened 3 months ago

saschabrockel commented 3 months ago

Describe the bug I'm running this health command curl --fail http://localhost:8080/api/health || exit 1 for the health check of the container. Since the newest update, it's not working anymore. I can do the exact same command in the container itself without problems.

I'm on master#5977f7c.

The container health logs say the following OCI runtime exec failed: exec failed: unable to start container process: exec: "/bin/sh": stat /bin/sh: no such file or directory: unknown

saschabrockel commented 3 months ago

Sorry but what is the fix? I cannot see it.

I'm using it like this: --health-cmd="curl --fail http://localhost:8080/api/health || exit 1" --health-interval=1m --health-timeout=10s --health-retries=3

It is done as recommended. I don't think it has anything to do with this.

AnalogJ commented 3 months ago

apologies, I referenced the wrong Issue. Here's the correct one - https://github.com/AnalogJ/scrutiny/issues/601

Basically if you're using Docker-compose, you need to specify the shell array syntax.

I'm actually not sure if theres a way to do that when using the docker cli...

Let me re-open this issue.

AnalogJ commented 3 months ago

looks like a known issue without any fix:

AnalogJ commented 3 months ago

I considered baking the healthcheck into the docker build, however that will cause issues for users that change their default port.

Might still be worth it

TimGels commented 2 months ago

Did that baking in already happen? I am unable to use Scrutiny now as I have put it on a different port. Changing the port back to 8080 seems to work, otherwise the web container says it's unhealthy. But is not really a good solution as it is a very common port which I do not want to dedicate to Scrutiny. I don't think that breaking the possibility to change ports is the way forward.

Okay no, my issue seems unrelated. But I still think creating issues for users who change the default port is not a good balanced decision compared to the advantages.