Factorio - Default uses --start-server launch argument, but prone to cascading autosave failure?

[Doug-Murphy]

I went on vacation a few days ago and left my dedicated server running. When I returned today and loaded into my server, I quickly noticed that it was back at the starting point with the crashed ship. I did some looking at my autosaves and the famous save1.zip that is part of the launch arguments and noticed that my save1.zip had a timestamp of when I first started up the server. All of my autosaves had been, as expected, the last 5 autosaves all 10 minutes apart. At some point over my vacation, the server had restarted and loaded in the initial (read-only by Factorio design apparently?) save1.zip and then all of the autosaves from there wrote that same save game until my server had all backups completely removed. I am using the Docker image for this, in case that helps explain why this may have happened.

My question here is "Should we be using --start-server ${serverfiles}/save1.zip in the launch arguments or should we instead use --start-server-load-latest?"

With --start-server-load-latest, it automatically loads the latest autosave when the server boots. I was able to successfully verify this by adding startparameters="--bind ${ip} --start-server-load-latest --server-settings ${servercfgfullpath} --port ${port} --rcon-port ${rconport} --rcon-password ${rconpassword}" to my /data/config-lgsm/fctrserver/fctrserver.cfg file. Upon launching the server, the latest autosave is the file that had loaded up. For good measure, I even renamed my save1.zip so that there was no save1.zip for it to somehow sneakily use.

[Doug-Murphy]

Proposed fix in #4960

[Doug-Murphy]

I was running some tests, and found that my server ran out of disk space. As a result, Factorio was not able to save to the latest _autosaveN.zip file. Because of that, the Factorio server crashed, but not the Docker container, and it (reasonably so) restarted itself. Because the launch arguments had --start-server ${serverfiles}/save1.zip pointing to the initial save1.zip, the server must have rebooted with that initial save and then was able to overwrite all existing autosaves since the new save would have been smaller.