When everyone disconnects, first establish whether the Satisfactory process actually exited. A failed join with a running server belongs to connection troubleshooting; an exited process needs a timeline showing what killed it. Reinstalling immediately can erase useful evidence while leaving the cause unchanged.
This guide covers an existing PC, unmodded, native Linux server managed by systemd. Examples match our setup: satisfactory.service, account satisfactory, installation /home/satisfactory/server, HOME /home/satisfactory. Replace them with your verified values. Containers have additional memory limits and mounted paths; Windows requires its own event and service tools.
Capture the failure before another restart#
Record the failure time and timezone, affected session, last successful save and whether it happened during loading, joining or saving. Note recent changes to the game build, mods, host resources or storage. A repeatable crash on one checkpoint differs from every world failing at startup.
Run these read-only checks over SSH:
sudo systemctl show satisfactory.service \
-p ActiveState -p SubState -p Result -p MainPID \
-p ExecMainCode -p ExecMainStatus -p NRestarts
sudo systemctl cat satisfactory.service
sudo journalctl -u satisfactory.service --since '-30 minutes' \
--no-pager -o short-iso
sudo journalctl -k --since '-30 minutes' --no-pager -o short-iso
NRestarts and the unit journal help identify an automatic restart loop. An active process now may be a replacement for the one that crashed. systemctl's status properties describe the current or retained invocation; older attempts require journal history. Preserve the relevant interval before rebooting. The kernel command shows the current boot's kernel journal, subject to permissions and retained logs. Missing output does not prove there was no OOM event.
Find ExecStart, working directory, user, HOME overrides and any ExecStartPre updater. Keep a private copy of the evidence. Unit files and logs can contain passwords, tokens, addresses and player information; redact them before posting publicly.
Separate the game error from the crash reporter#
For the example installation, inspect the actual game's log:
sudo tail -n 200 /home/satisfactory/server/FactoryGame/Saved/Logs/FactoryGame.log
sudo ls -lt /home/satisfactory/server/FactoryGame/Saved/Crashes
These are common installation-relative locations in the dedicated-server file reference, not universal paths. A missing directory should trigger path and launch-output checks. Look earlier than the final shutdown lines: the crash-reporting process exiting is not necessarily the original failure.
An allocation failure, assertion, missing library and permission error require different repairs. Match the first relevant error to the kernel and unit timestamps. If the unit reports a signal kill without a game stack trace, check the host's explanation before changing game settings. SIGKILL, or a wrapper exit code such as 137, alone does not identify the OOM killer: an operator or timeout handler can also kill a process.
Check host headroom and the service's limit#
free -h
sudo systemctl show satisfactory.service \
-p MemoryCurrent -p MemoryPeak -p MemoryHigh -p MemoryMax \
-p EffectiveMemoryMax -p ControlGroup
The available column in free estimates memory available to new work; a low free column can simply reflect cache. These are present-time observations, not the memory level at the crash. Capture a repeated trend during a controlled reproduction instead of inferring a leak from one sample.
A server can hit a service or parent-slice ceiling while the host still has available RAM. systemd's resource-control reference explains that MemoryMax is a hard boundary and an ancestor can impose a tighter effective limit. Some properties depend on systemd version and accounting support; absent values are not proof of unlimited memory.
On a cgroup-v2 host, use the nonempty ControlGroup path from that output to inspect memory.events while that cgroup exists. Compare counters before and after the same failure. The kernel documentation distinguishes allocation failure at the cgroup limit (oom) from processes actually killed (oom_kill). Counters accumulate and can include descendants; correlate their change with the correct instance and timestamps. A removed cgroup may no longer be inspectable after the crash.
If the evidence confirms a limit issue, change the owning service/container configuration only after checking capacity for the OS and other workloads. Do not simply remove all limits. If the entire host is exhausted, reduce competing workloads or provision capacity based on measured peaks, including load/save phases. Swap can change failure behavior but does not turn storage into equivalent RAM or repair a game defect.
Check storage before deleting anything#
Persistent saves and installation logs can live on different filesystems:
sudo df -h /home/satisfactory/server /home/satisfactory/.config/Epic/FactoryGame/Saved
sudo df -i /home/satisfactory/server /home/satisfactory/.config/Epic/FactoryGame/Saved
sudo -u satisfactory test -w /home/satisfactory/.config/Epic/FactoryGame/Saved/SaveGames/server
File allocation and inode capacity are separate checks. A full inode table can prevent new files even with free bytes. The write-access check returns no text; inspect its exit status. It checks directory permissions, not a successful game save, quota allowance or healthy storage.
If a path is missing, confirm the service's actual HOME before creating replacements. For Permission denied, inspect the affected file and each parent directory; avoid recursive permission changes across the whole home directory. For a full disk, copy necessary logs and backups off-host, then remove only identified disposable files. Preserve the last usable checkpoint and a current-state backup.
Verify one repair against the original trigger#
Change one cause at a time. Before a controlled test, preserve the affected checkpoint using the backup procedure. For an actively looping unit, collect evidence, then stop that unit deliberately during maintenance. Confirm it has stopped before changing its files.
If the instance is managed through Nexardo on your own Linux infrastructure, make lifecycle changes through that instance’s controls and compare its logs with the host evidence. Keep the same original workload for the verification.
Start the intended instance, watch its new journal and reproduce the original loading/joining/save condition. Verify the correct factory, complete a new save, then perform a graceful restart and rejoin. Monitor both host headroom and the service ceiling through that interval. A stable process without the original workload is incomplete evidence.
If the crash repeats without OOM or storage evidence, retain the first game error, build, branch, checkpoint and reproduction steps. Compare with an isolated compatible instance using a copy of the save; do not replace the live factory with a new world just to test. Submit a redacted report through Coffee Stain's support destination. A matching report is useful context, but its workaround is not automatically safe for your build.
