Rust Server Stuck on Startup or Not Responding

A Rust server that has been "starting" for five minutes is usually fine. One that has been starting for an hour is not. Both look the same from the outside: players cannot connect, the server is not in the browser, and RCON tools time out. This guide shows what a normal start looks like with real timings from our test host, how to tell a slow start from a real hang, and how to recover without losing anything.

A normal start, with real timings

Every start goes through the same milestones in the console output. On our 4 vCPU, 8 GB Ubuntu test host with a 4000 map, the journal looks like this:

Two things trip people up:

• Generating procedural map is printed on every start, even when the server just loads the map file it generated last time. It does not mean the map is being rebuilt. The step timings tell you: [0.7s] Loading World and a few seconds of Processing World means a cached map; a Processing World step of several hundred seconds means a real generation.
• New maps take minutes. On our host, generating a 4000 map took a little over six minutes (380 seconds) and the whole start about eight and a half. Bigger world sizes and slower CPUs take longer. The log can sit on one step for minutes during generation; that is normal.

Memory matters too. Before we resized the same host from 4 GB to 8 GB, a new 4000 map never finished: the kernel killed the process at a 3.3 GB peak about 15 seconds into generation, nine times in a row, each ending in Failed with result 'oom-kill'. That is a crash loop, not a hang: the PID changes and NRestarts grows. See the systemd service guide for reading those exits.

Why RCON does not answer during startup

The RCON port opens 10 to 30 seconds after launch, long before the world exists. Your RCON tool connects fine, then commands time out. That is expected: the server accepts connections early but does not reliably answer commands until startup is done.

We saw this from the agent side during a map generation: requests piled up without replies until the agent hit its limit of 10 requests in flight and started refusing new ones with "RCON busy". Our agent also found that a lightweight echo can get a reply before the server is really ready, so it waits for two serverinfo replies in a row before it treats a server as up.

So during the first minutes after a start, a silent RCON is not a signal of anything. After Server startup complete, it is.

The real hang: what it looked like

On 27 September 2026 our test server got stuck for real, and the logs are a good example of what to look for.

A new Carbon install had just been activated with a restart, and a minute later Carbon's files were removed from disk while that new process was still generating the map. Carbon was already loaded into the running process, so it kept going. Generation finished normally ([380.3s] Processing World). Then:

22:06:23 SteamServer Initialized
22:06:23 DirectoryNotFoundException: Could not find a part of the path ".../carbon/logs/Carbon.Bootstrap.log".
22:06:23   at Carbon.Hooks...IOnServerInitialized.Postfix ()
22:06:24 SteamServer Connected
22:08:36 [RustNav] Navmesh 'default' is now fully built in 182.42 seconds (140625 tiles).

After that, nothing. No Server startup complete, no Saving complete, no RCON replies, for 58 minutes, while the process kept burning CPU: systemd later reported 1 h 45 min of CPU time over 1 h 8 min of wall time. The exception came from Carbon's hook that runs when the server finishes initializing, and startup never completed after it.

Two lessons from this one:

• Never remove Oxide or Carbon files under a running server. Stop it first, remove the files, then start it. The same goes for installing: a framework only activates on the next start.
• SteamServer Connected is not the finish line. On a healthy start it comes right after Server startup complete. On this one it came without it.

Stuck or just slow: how to tell

Work through these in order. The journal is the most reliable signal.

1. Which milestone was the last one? Show the milestones with timestamps:

journalctl -u rust-server --since "1 hour ago" -o short-iso \
  | grep -E "Generating procedural map|Processing World|Couldn't load|SteamServer|Server startup complete|Saving complete"

• Last line is Generating procedural map and it is less than 15 minutes old: slow, not stuck. Wait.
• Server startup complete is there: the server is up. If players still cannot connect, look at ports and the firewall, not at startup.
• SteamServer Initialized or Connected is there but no Server startup complete, and minutes pass: suspicious. Read the lines right before for an exception, especially from a plugin or framework.

2. Is the journal silent? A running server writes Saving complete every server.saveinterval seconds (600 on our host, so every 10 minutes). A server that has been silent for longer than that, after startup should have finished, is stuck. During map generation long quiet stretches are normal, so this check only counts after generation is done.

3. Is it the same process? If the PID keeps changing, it is a crash loop, not a hang:

systemctl show rust-server -p ActiveState -p MainPID -p NRestarts

4. CPU, with care. A healthy Rust server's main thread runs near 100% of one core all the time. On our test host, top -H -p $(pgrep RustDedicated) shows the main thread at 99.9% on a server that is running perfectly. High CPU does not mean stuck. Zero CPU for minutes on the main thread does mean something is wrong (a stopped process looks like this).

5. Give it a deadline. If it is past 25 minutes on a normal map with no new log lines, stop waiting. That is the threshold Panelra uses, chosen to sit well above the slowest normal start we have measured.

Safe recovery: kill, then start

If the server never printed Server startup complete, it has not saved anything since it started. Nothing is lost by killing it. Use SIGKILL, not a normal restart:

sudo systemctl kill -s KILL rust-server
sudo systemctl start rust-server

Why not systemctl restart? A restart sends SIGTERM and waits for the process to exit, up to TimeoutStopSec (90 seconds by default, and on our units). A frozen process can still exit quickly: in our test with a SIGSTOPped server, systemctl restart finished in 6 seconds. But if a hung process does not exit on SIGTERM, you wait the full 90 seconds for systemd to log State 'stop-sigterm' timed out. Killing. and send the SIGKILL anyway. Going straight to SIGKILL skips that wait.

What to expect in the journal:

Sent signal SIGKILL to main process 87188 (bash) on client request.
Killed unit cgroup '/system.slice/rust-instance-....service' with SIGKILL on client request.
Main process exited, code=killed, status=9/KILL
Failed with result 'signal'.
Scheduled restart job immediately on client request, restart counter is at 1.

systemctl kill signals every process in the unit, including a wrapper script such as carbon.sh. With Restart=always, systemd would start the unit again by itself after RestartSec (5 seconds on our units). The systemctl start skips that delay, which is what Scheduled restart job immediately on client request records, and it also covers units without automatic restart.

After the kill:

• If generation had finished, the map file is already on disk and the next start reuses it. Our stuck server came back in 85 seconds.
• If you killed it during generation, generation starts over. That is why you should not kill a server that is merely slow.
• If a framework was half removed, fix that first or the next start may fail again. In our case the unit still launched through carbon.sh, which printed environment.sh: No such file or directory and started the server without Carbon.
• If the server was already running and stopped responding later, a SIGKILL loses everything since the last Saving complete, up to one save interval. Try server.save over RCON first; if RCON does not answer, the kill is still the only way out.

What Panelra does about it

Panelra's agent watches both phases, so you are not the one checking logs at 3 a.m.:

• Starting. The agent probes the server with serverinfo over RCON and only marks it running after two successful replies in a row. While it is starting, the panel shows it as starting and warns you before a stop or restart that would throw away a map generation in progress.
• Stuck while starting. If a server has been starting for more than 25 minutes and its last three or more probes failed, the agent raises a "stuck while starting" alert in the panel and on Discord, refreshed every 5 minutes while it lasts. It closes on its own if the server reaches running.
• Not responding while running. Probes run about every 15 seconds; after at least 3 minutes of failures you get a "not responding" alert. On a frozen test server it fired after 3 minutes 34 seconds.
• Force restart. Stop and Force restart are available while a server is starting (Operator role or above). Force restart marks the restart as planned, sends systemctl kill -s KILL, and starts the unit again, so the kill is not reported as a crash.
• Framework changes are safe. Uninstalling Oxide or Carbon stops the server first, and the agent refuses to delete framework files while the unit is still active, so the incident above cannot happen through the panel any more.

See alerts, server monitoring and the RCON console.

Let Panelra watch it for you

Install the agent on your Linux host and every server gets startup tracking, hang and stuck-start alerts, crash and OOM detection, and a force restart button that does the safe kill for you. Your units and logs stay on your host, and journalctl still works exactly as in this guide. For a first install, start with installing a Rust server on Ubuntu; for new maps, see how to wipe a Rust server.

Free during the open beta. Pricing will be announced before the beta ends.