The default healthcheck settings usually are too strict for modded servers

[n1xx1]

Enhancement Type

Improve an existing feature

Describe the enhancement

I was experiencing this issue when using a compose stack deployed on Docker Swarm. In portainer it didn’t even report a failed healthcheck as the reason the container got killed, but only a 137 exit code that is usually associated with the kernel OOMKiller killing the process.
The suggestion I have is either modify the healthcheck scripts to wait until the server no longer responds with a “server starting” error and increasing the timeout allowed in the healthcheck settings, or increase number of tries / interval / start period. If you don’t want to do that for all the server types maybe it could be specified in the readme that the default settings aren’t usable for a modded server and suggest to change them in the compose file.

Thanks!

[itzg]

In portainer it didn’t even report a failed healthcheck as the reason the container got killed, but only a 137 exit code that is usually associated with the kernel OOMKiller killing the process.

Are you sure the container didn't exceed the container memory limit?

The suggestion I have is either modify the healthcheck scripts to wait until the server no longer responds with a “server starting” error

That defeats the point of a readiness check with timeout. "server starting" is basically the condition that readiness is checking for.

If you don’t want to do that for all the server types maybe it could be specified in the readme that the default settings aren’t usable for a modded server and suggest to change them in the compose file.

I'm sorry, I can't document every helpful aspect of Docker that might be relevant to this image. Usage of the image assumes an ability of the user to go reference and use the Docker reference material.

[n1xx1]

Are you sure the container didn't exceed the container memory limit?

Yes, of course. The issue is with the healthcheck, with more relaxed settings it works just fine.

That defeats the point of a readiness check with timeout. "server starting" is basically the condition that readiness is checking for.

"server starting" is an error state according to the healthcheck, so if it fails the container will be as unhealthy until it actually starts. Which in turn means the docker service will kill the container after 3 healthcheck tries, which often is too soon for a modded minecraft server.

I'm sorry, I can't document every helpful aspect of Docker that might be relevant to this image. Usage of the image assumes an ability of the user to go reference and use the Docker reference material.

While I understand your point, the defaults used in the image produce a not working container when used in a docker service, which, in my opinion, is a valid way to use the image.

Also, I personally don't care about the problem, now that I know what's going on it's as simple as changing the healthcheck settings in the docker-compose file, but I thought this could help other that smash their head in the problem, since it's so easy to mistake for a OOM issue.

[itzg]

While double checking my PR would fix your issue #1617 I realized that the health check wasn't allowing enough time 😁

So, I increased the default retries and added a brief explanation of increasing that to the README.