Factorio docker container instance not gracefully shutting down when shutdown/reboot on host is executed

[dreamdenizen]

Operating System

Debian 12/13, Ubuntu 24.04.3

AMP Version and Build Date

2.6.2.6 - 20250804.1

AMP Release Stream

Mainline

I confirm that

• I have searched for an existing bug report for this issue.
• I am using the latest available version of AMP.
• my operating system is up-to-date.

Intended Action

I am trying to shut down or reboot the host machine (Debian 12/13, Ubuntu 24.04) while a Factorio instance is running.

Expected Behaviour

When the host machine shuts down, I expect the Factorio game server instance to perform a graceful shutdown. This should save the current game state to the default.zip save file, preserving all player progress, exactly as it does when the "Stop Instance" button is used in the AMP web panel.

Actual Behaviour

When the host is shut down or rebooted (e.g., via sudo reboot), when the "Enable Auto Pause" setting in the Factorio module is disabled, the Factorio instance terminates abruptly instead of shutting down gracefully. This prevents the server from saving the latest game state. As a result, all progress made during that play session is lost, and the save file reverts to the state it was in at the last startup.

I have reviewed the instance logs from the time of the shutdown. There are no explicit error messages. The log simply stops, which makes me think the process was likely terminated uncleanly rather than being issued a graceful stop command.

Reproduction

1. Start with a clean install of AMP on Debian 12/13 or Ubuntu 24.04.x using the standard installation script. Set it up in Docker mode.
2. Create and start a new Factorio instance.
3. Double-click the instance
4. Navigate to Configuration > Factorio
5. Set "Enable Auto Pause" to disabled.
6. Set "Make Server Visible Publicly" to disabled
7. Restart the instance for the setting to take effect.
8. Connect to the game server from the Factorio client and play for a few minutes to create new progress (e.g., move your character, chop a tree).
9. Disconnect from the game server, leaving the instance running in AMP.
10. Connect to the host machine via SSH.
11. Execute the command sudo reboot.
12. After the host machine reboots, start the Factorio instance again.
13. Connect to the game server from the Factorio client. You will find that all progress from the previous session has been lost, and the game starts from the beginning again.

[dreamdenizen]

I tested behavior in non-Docker mode, and Factorio is gracefully exiting when reboot and/or shutdown is executed from the host terminal, and when passed in by the hypervisor via qemu-guest-agent, so the issue seems isolated to Docker mode.

[BroOtti]

Duplicate of #1019

[dreamdenizen]

Version: 2.6.2.8 - 20250916.2
OS: Debian 13.1 amd64

Did some more testing tonight. I'm still seeing the original behavior I reported. When in non-container mode, on system shutdown, the factorio process saves the game and gracefully exits. If I switch it to Docker mode, it just exits, without saving. Switching it back to non-container mode restores expected behavior.

[BroOtti]

Can you start the instances and the game server and then stop the instances and share latest AMP log for both cases?

[BroOtti]

If it's only happening on system reboot, you may need to change manually the service until the changes are merged.
#1356

Would still love to see the AMP log for non docker instances. Maybe I will see something there which helps to find out why my non docker instances are killed instead gracefully stopped

[dreamdenizen]

If it's only happening on system reboot, you may need to change manually the service until the changes are merged. #1356

Would still love to see the AMP log for non docker instances. Maybe I will see something there which helps to find out why my non docker instances are killed instead gracefully stopped

Sorry for the delay in response. Did some more testing and I’m able to reproduce non-graceful shutdown in non-containerized mode from time to time too, but not 100% of the time like containerized ones. AMPs log’s don’t show anything of note either. I’ll try to dig deeper as time permits.