When Your Game Server Exits Silently: Read stderr.log Instead of stdout.log
The most confusing failure mode for a dedicated server is the silent one. The panel shows the server going from starting → offline. The visible log only contains Starting server... and nothing else. The customer sees no error and assumes the panel is broken.
It usually is not. The error is real, it just landed on the wrong stream.
Why stdout looks empty
Linux processes write to two output streams: stdout for normal informational output, and stderr for errors and warnings. Some game servers write almost everything to stdout. Others (Windows-binary games running on Linux, Java JVMs, Unity headless builds) write the boot handshake and any fatal startup error to stderr only.
If the panel only displays the stdout stream by default, an early-boot fatal error never appears in the UI. The server exits, the panel shows "offline", and the only diagnostic clue is in a file you have to open by hand.
The standard log layout
Every game server on a Supercraft node uses the same on-disk layout inside the server's files. Substitute {game} with the game code (vlh, prz, stf, vst, ens, pal, arksa, unt, etc.). Paths below are relative to the server's root directory (what you see when you connect via FTP):
{game}/process-control/
├── stdout.log # primary game stdout, normal output
├── stderr.log # silent-exit signatures land here
├── stdin.log # commands sent to the server
├── run_watch.stdout.log # process supervisor stdout
├── run_watch.stderr.log # supervisor stderr (most useful for "why did it die?")
├── pidfile # if present, server is running
└── input-fifo # named pipe for live commands
{game}/logs-arch/
└── std{out,err,in}-<timestamp>.log # archived logs from prior runsThe order to check, when stdout is empty:
stderr.log: game's own error stream.run_watch.stderr.log: wrapper supervisor; this catches non-zero exit codes and crash signals.logs-arch/stderr-<timestamp>.log: the previous run if the current one already rotated.
What "silent exit" actually looks like
A real fingerprint from a Valheim deployment that "wouldn't start" but had no stdout error. The customer reported: "Start spins for a while, then stops. Logs only show 'Starting server...'". The actual stderr.log contained:
[S_API] SteamAPI_Init(): Loaded local 'steamclient.so' OK.
Setting breakpad minidump AppID = 892970
SteamInternal_SetMinidumpSteamID: Caching Steam ID: ********** [API loaded no]
[S_API FAIL] Tried to access Steam interface SteamNetworkingUtils004 before SteamAPI_Init succeeded.
src/clientdll/cminterface.cpp (2253) : !BLoggedOn()The diagnostic is the [API loaded no] tag and the !BLoggedOn() assertion. Steam's local API loaded the shared library but failed to authenticate, so every subsequent interface call returned null and the process exited. None of that ever reached stdout.
Common silent-exit signatures by game family
| Game / runtime | What lands in stderr.log on silent exit | Real meaning |
|---|---|---|
| Valheim, Satisfactory, Vintage Story (native Linux) | [API loaded no], !BLoggedOn() |
Steam authentication failed at boot. Usually a transient Steam outage or a stale steamclient cache; restart the deployment. |
| Project Zomboid (JVM) | Java stack traces from zombie.network.GameServer.main |
Map corruption, mod incompatibility, or RAM ceiling. The first Caused by: line names the cause. |
| ARK: Survival Ascended, Enshrouded, Palworld | trace:steamclient: noise plus a final non-zero exit |
The trace lines are normal runtime output. The actual error is the last few non-trace lines before the supervisor logs the exit. |
| Anything (kernel-level) | Empty stderr, supervisor logs Killed or signal 9 |
Out-of-memory kill. Check your RAM allocation; the game was killed by the kernel before it could write anything. |
What is not a real error
A few lines look alarming but are normal on servers that run Windows-built games on Linux. Ignore them if the server is otherwise running:
[S_API FAIL] Tried to access Steam interface SteamNetworkingUtils004 before SteamAPI_Init succeeded.: initial Steam handshake ordering, recovers automatically.019c:trace:steamclient:winISteamGameServer_SteamGameServer015_GetNextOutgoingPacket: a normal trace channel from the runtime, not an error.src/clientdll/cminterface.cpp (2253) : !BLoggedOn()on its own: the same handshake retry loop. Only treat as fatal if the server then exits.
The rule is: a silent exit after these lines means they were the cause. If the server stays online, they are noise.
Reading the supervisor stream
If both stdout.log and stderr.log are empty, the supervisor caught the exit before the game wrote anything. That information lives in run_watch.stderr.log. It typically contains the exit code and the signal:
process exited with code 1
process killed by signal 9 (out-of-memory kill)
process killed by signal 11 (segmentation fault)
process killed by signal 15 (clean shutdown / SIGTERM)Signal 9 is the kernel killing the process for using too much memory. Signal 11 is a crash in the game binary; the next step is enabling crash dumps if the game supports them.
Quick checklist when "logs only show Starting"
- Open
stderr.log, notstdout.log. - If stderr is also empty, open
run_watch.stderr.logfor the exit code. - Look at
logs-arch/for the previous run if the current run already rotated. - Match the signature to the table above.
- If the signature is a Steam handshake failure, restart the deployment once. If it persists across restarts, file a ticket with the stderr excerpt.
Why this matters: "the server stops after a few seconds" with only Starting server... in the visible log is almost always a real error written to the wrong stream. Reading stderr.log first turns ten minutes of guessing into a one-line answer.
Servers with the right diagnostic surface
Supercraft hosting exposes both stdout and stderr in the panel and keeps archived runs in logs-arch/ so you do not have to rebuild the timeline from a single live tail. If you are hunting a silent exit, the previous run's stderr is usually the most useful file on disk.