quit/stop/exit command in console doesn't stop the server

[MaciejGorczyca]

Attempting to stop the satisfactory server by using the built-in commands (quit/stop/exit)will simply lock the container - the server won't be in usable state but it also won't shut down.

There will be a bunch of logs indicating that the server is stopping:

[2022.07.10-01.34.35:451][236]Closing by request

[2022.07.10-01.34.35:451][236]LogCore: FUnixPlatformMisc::RequestExit(0)

[2022.07.10-01.34.35:451][236]LogGenericPlatformMisc: FPlatformMisc::RequestExit(0)

[2022.07.10-01.34.35:451][236]LogCore: Engine exit requested (reason: GenericPlatform RequestExit)

[2022.07.10-01.34.35:451][236]LogServerConnection: Closing by request

After a bunch of logs the container will simply sit there forever. The players can't restart the server by telling the server to shutdown because container will not shutdown as well (then restart after that because of restart: always line).

[wolveix]

Hey! Thanks for taking the time to open this issue :)

This sounds like a bug with the server executable not properly terminating, meaning the container wouldn't know to stop/restart.

I'll do some testing on my end. If it is a bug with the server executable, then there's nothing I can do.

[blitzcaster]

I'm also experiencing this, container hung up until timeout and Podman sends SIGKILL. Is this confirmed as server/game issue instead of the image?

[wolveix]

From my testing, this appears to be a game server issue. You can safely stop the container without issues, it's only when executing commands directly from the game. We may be able to get around this, but it would require some work, specifically around the init.sh structure.

I've got a few features planned that may go hand in hand with this potential fix, so I'll keep this issue open for the time being

[blitzcaster]

From my testing, this appears to be a game server issue. You can safely stop the container without issues, it's only when executing commands directly from the game. We may be able to get around this, but it would require some work, specifically around the init.sh structure.

I've got a few features planned that may go hand in hand with this potential fix, so I'll keep this issue open for the time being

Does using dumb init such as tini or catatonit helps? I've experience some program myself that have problem forwarding SIGNAL without proper init system. I don't know it will help, but maybe worth the shot.

• tini (probably easier since precompiled on some distributions) https://github.com/krallin/tini

• catatonit (may require manual compilation, never tried it myself) https://github.com/openSUSE/catatonit

[wolveix]

Sorry about this being left for so long. After testing, it does appear to be a game issue, not a container issue. gosu sets the binary call to PID 1, and requesting to stop the container twice does in fact stop it. After attempting to stop it once, you can see from the container logs that the world/save gets stopped, but the server itself stays online.