STYGION Panel a0.3.4

Two faults that were holding each other up, found by running 0.3.3 against a live server an hour after releasing it.

A stop the server ignores now actually stops it

stopGraceTimeout was thirty seconds and the REST handler's budget is also thirty — so the wait and the budget expired together. The fallback to SIGTERM/SIGKILL never ran, the caller got context deadline exceeded, and the container carried on. The row in the database stayed on "running" as well, because the refresh after the action never happened either.

Measured on production: a server that ignores both its stop command and SIGTERM could not be stopped at all. It now stops in thirty seconds and answers with the server, not an error.

• The lifecycle work is detached from the request that asked for it. Whoever asked may walk away — a closed tab, a proxy, the REST timeout — and the action still finishes and the row still ends up true.
• The grace is twenty seconds out of forty-five, so there is room for the hard stop after it.
• GracefulStop no longer returns an error and leaves on a cancelled context. Whatever else happens, the container is stopped before it returns.

A container is never rebuilt while it is running

0.3.3 moves an older container onto the console pipe at its next Start. But create --replace force-removes whatever is in the way, so doing that to a container that is still up is a hard kill with no save.

Start is reachable while a server runs — precisely because a stop could overrun and leave the row saying one thing and the engine another — and this morning the two met on a live Minecraft server. The rebuild now checks the state first, and there is a test that holds it there.

---

Upgrading from 0.3.3 needs nothing of you.