Start with the lifetime of the actual Rust process. A panel displaying “generating map” for an hour might describe one slow start, repeated failed starts, or a stale status after the process exited. Those cases need different fixes. Deleting the world before distinguishing them removes evidence and risks the players' progress.
This guide covers Rust PC on Ubuntu, following our server setup: systemd service rust, account rust, installation /srv/rust/game, identity friends, log /srv/rust/rust.log. Substitute your actual paths. Console Edition and a player's loading screen are outside this procedure.
Find out whether the process keeps restarting#
Inspect the service and recent game output before pressing Restart again:
sudo systemctl show rust -p ActiveState -p SubState -p MainPID -p NRestarts -p ExecMainStartTimestamp
sudo journalctl -u rust --since '-20 minutes' --no-pager
sudo tail -n 100 /srv/rust/rust.log
Repeat the first command later. A new process ID or start time means the current attempt is younger than the panel suggests. A rising restart counter helps identify a service restart loop; an external panel or watchdog can also initiate restarts, so check that scheduler separately. Preserve the first error preceding each exit.
If generation is progressing, stop issuing restarts. An automatic health check that expects players to join immediately can keep killing otherwise useful startup work. Adjust that particular readiness grace period only after confirming the process is making progress; do not disable recovery permanently to conceal a crash.
A historical administrator discussion shows the ambiguity: one reply proposed deleting old saves, while another reported the same symptom on a fresh server. A status message alone cannot establish save corruption.
Compare progress with resource evidence#
Read two log samples several minutes apart and note the last completed stage, timestamps and any exception. There is no dependable universal “generation must finish in five minutes” limit. Compare equivalent map settings and server builds with your own previous successful startup, when available.
free -h
df -h /srv/rust
df -i /srv/rust
sudo ps -u rust -o pid,etimes,%cpu,%mem,rss,comm
sudo journalctl -k --since '-30 minutes' --no-pager
In free, examine available memory rather than treating a small free column as exhaustion. Swap activity and sluggish I/O deserve investigation, but memory use by itself does not prove a leak. Kernel messages identifying an OOM victim are stronger evidence of memory pressure. On a shared host, distinguish the Rust process from unrelated workloads.
Check disk space and inodes independently: either can prevent new files being written. A stable PID with changing log stages and active CPU suggests work continues. Repeated exceptions, OOM termination, storage errors or unchanged observations over several samples justify investigating the specific failure. Low CPU alone does not identify the cause; the process may be waiting on disk or a download.
Reconcile the world settings before changing them#
Check server.identity, map type, seed, size and any custom-map URL in the existing launch configuration. Inspect service definitions privately; their arguments may contain RCON credentials. Then inspect the map settings below privately too: a signed custom-map URL can contain access tokens. Remove those tokens before sharing any output:
sudo sed -n '/^server\.level /p; /^server\.seed /p; /^server\.worldsize /p; /^server\.levelurl /p' /srv/rust/game/server/friends/cfg/server.cfg
Facepunch documents that server.cfg takes precedence over command-line values. Editing a launch seed while leaving another in this file can make a test misleading. Changing the identity can also load a different directory that appears to be an empty world. Record the effective settings before editing them.
A larger procedural world increases resource demands. Reducing its size on the live identity is a world change, not a harmless performance switch. If comparing a small vanilla map is necessary, use an isolated installation and identity with different ports and no player access; never point the experiment at production data.
For a custom map, investigate download errors before procedural-generation settings. Facepunch's custom-map guide requires a direct map URL, accessible to new players too. A login page or an HTML download wrapper cannot substitute for the map file. Preserve the map currently associated with the save while checking the URL and expected asset version.
Archive the stopped state before a controlled change#
If the evidence calls for a restart or repair, announce maintenance and suspend external start schedules. Stop the service, confirm its main process is gone, and check that no independently launched Rust process is still writing this identity:
sudo systemctl stop rust
sudo systemctl show rust -p ActiveState -p SubState -p MainPID
sudo pgrep -u rust -x RustDedicated
No pgrep match normally exits with status 1. Resolve any remaining writer before proceeding. Create a private, timestamped backup outside /srv/rust; include the complete tree, service definition and any external plugin stores. Check archive readability and keep an off-host copy. A live copy of a changing save and its database journals is weaker recovery material than a stopped snapshot.
Change one evidence-backed item: available capacity, permissions, the failing download or a documented incompatible extension. Preserve the previous configuration and game build information. Avoid deleting .sav, blueprint databases or the whole identity as a generic generation fix.
Confirm the intended world actually becomes usable#
Start once, watch the log and verify that the restart loop has stopped. After startup completes, a matching Rust PC client must join the intended game endpoint and reach the expected world. A UDP listener alone does not establish that the map loaded correctly.
If joining works but the public list is missing, continue with browser-discovery checks. If the world is unexpectedly empty, stop new player activity and inspect identity and map selection before allowing a save to replace useful recovery evidence. Finally, use a planned save and restart to confirm persistence; retain the pre-change archive until that check succeeds.
