Option to keep container alive after server stop (Process Supervisor)

[tekikaito]

Enhancement Type

A completely new feature

Describe the enhancement

Description:

Hi there! Thanks for maintaining this awesome image.

I’m currently building a custom Admin UI for my server that runs as a sidecar container alongside the Minecraft container. One of the main features I'm adding is a "Maintenance Mode" that allows me to stop the server process to modify config files and swap out mods (which requires the server to be stopped in most cases).

The Problem

Currently, when I stop the Minecraft server process (even gracefully), the container entrypoint exits, which kills the container. In my setup (Kubernetes), this restarts the entire Pod, which unfortunately kills my Admin UI sidecar right in the middle of the maintenance workflow.

Why existing solutions don't fit

I already considered just letting the container die and having my application trigger a restart externally (like calling the Kubernetes API to restart the Deployment). However, I decided against this because:

• Platform Coupling: It would force my app to know about the underlying infrastructure (K8s, Docker Swarm, plain Docker Compose).
• Complexity: I want my Admin UI to be platform-agnostic and "just work" with this container standard, without needing permission to talk to the cluster API or host daemon.

Request

First off, I absolutely love that we can already control the health check by modifying the mc-health.env file. That feature is amazing and is the first step to making my use case possible, as it allows me to tell Kubernetes the pod is "healthy" even when I've intentionally stopped the server for maintenance.

The final missing piece is to keep the container itself from exiting when the java process stops.

So, it would be amazing if there was a flag (e.g., KEEP_ALIVE_ON_STOP=true) or a supervisor mode that keeps the container entrypoint running even if the actual java process stops. This would allow a sidecar or local script to stop the server, do some work, and start it again—all without the container itself ever crashing or restarting.
Is this something that could be added to mc-server-runner?

Thanks

[itzg]

I'll give this some more thought, but yes you're on the right track that it'll be an enhancement to mc-server-runner. Off hand I'm thinking it would accept an argument to tell it not to fully exit and then use a new signal to tell it to start the original server command.

[itzg]

...or an extension of the newly added websocket support 🤔

cc @EmilyxFox

[EmilyxFox]

...or an extension of the newly added websocket support 🤔

cc @EmilyxFox

I've been thinking about this, but I'm not sure my imagination is there. How do you imagine these things interacting?

[itzg]

@EmilyxFox was wondering if this for-select loop

https://github.com/itzg/mc-server-runner/blob/458e00515e53c628c49799d47264e8fde35da883/main.go#L210

could also take into account some new commands via websocket to start an exited Minecraft service if that feature was enabled when runner was called.