Scheduling Automated Restarts

7 Days to Die dedicated servers — through the V2.5 "Survival Revival" and current V2.6 Stable releases — gradually accumulate RAM and CPU overhead the longer they stay up. The voxel world, chunk cache, entity tracker, and any installed overhaul mods all contribute. A scheduled restart on a predictable cadence is the simplest fix and the lowest-effort uptime policy. This guide covers the pre-shutdown commands you must run, three implementation patterns (in-game scripted, OS-level scheduler, third-party tool), and the warnings that bite people who skip the save step.

Why Automate Restarts?

  • Reclaim RAM. Long-running servers grow as chunks load and entities accumulate. mem/memcl calls help, but a full process restart is the only way to fully release allocator overhead.
  • Reset entity churn. Wandering hordes, screamer cascades, and animal spawns add up over hours. After a restart the entity table starts clean.
  • Recover from a stuck tick. If physics or AI desyncs (rubber-banding, stuck zombies, frozen vehicles), a clean restart usually fixes it without needing further diagnosis.
  • Predictable downtime for players. A documented "we restart at 04:00 server time" is far better than random outages.

Always Save First — Then Shutdown

Both commands are real, server-supported, and safe to script.

CommandShortcutWhat it does
saveworldsaManually flushes the world to disk. The game also auto-saves periodically, but a forced save right before shutdown closes the gap between the last auto-save and the shutdown moment.
shutdown—Saves and exits the server cleanly. Always preferred over killing the OS process — a kill mid-tick can corrupt the chunk file currently being written.

Best-practice sequence (whatever scheduler you use):

  1. Broadcast a warning ~5 minutes ahead with say "Server restarts in 5 minutes — finish your run."
  2. Final warning at ~1 minute: say "Restart in 60 seconds."
  3. Run saveworld, wait ~10 seconds for it to complete.
  4. Run shutdown.
  5. Service supervisor (systemd, your hosting panel, etc.) brings the server back up.

Method 1 — systemd timer + telnet

Most Linux dedicated-server installs use a systemd service unit, which means you can drive the restart sequence with two extra units: a wrapper script that talks to the server's telnet socket, and a timer that fires it on schedule.

Telnet is built into the dedicated server (configured in serverconfig.xml via TelnetEnabled, TelnetPort default 8081, and TelnetPassword). Any client that can speak plain TCP — ncat, expect, your own script — can issue admin commands.

Sketch of a wrapper script (/usr/local/bin/7dtd-graceful-restart.sh):

# Replace TELNET_PASS with the value from serverconfig.xml.
# This relies on `expect` being installed.
expect <<'EXPECT'
spawn nc localhost 8081
expect "password:"
send "TELNET_PASS\r"
send "say \"Server restarts in 5 minutes.\"\r"
sleep 240
send "say \"Restart in 60 seconds.\"\r"
sleep 50
send "saveworld\r"
sleep 10
send "shutdown\r"
EXPECT
sleep 5
systemctl restart your-7dtd-service-name

Then a systemd timer runs that script daily at 04:00:

# /etc/systemd/system/7dtd-restart.service
[Unit]
Description=Graceful nightly 7DTD restart

[Service]
Type=oneshot
ExecStart=/usr/local/bin/7dtd-graceful-restart.sh

# /etc/systemd/system/7dtd-restart.timer
[Unit]
Description=Run 7DTD nightly restart at 04:00

[Timer]
OnCalendar=*-*-* 04:00:00
Persistent=true

[Install]
WantedBy=timers.target

Enable with systemctl enable --now 7dtd-restart.timer. The actual service-name in systemctl restart depends on how your install was set up (7dtd, 7d2d, sdtdserver, etc.) — adjust to match yours.

Method 2 — cron + telnet

Same principle, simpler runtime. Use cron if your host doesn't run systemd or you prefer crontabs.

# crontab -e
0 4 * * * /usr/local/bin/7dtd-graceful-restart.sh >> /var/log/7dtd-restart.log 2>&1

The wrapper script is identical to the systemd version above. Cron's downside vs. systemd timers: less helpful failure logging, no Persistent=true equivalent (a missed window because the host was down stays missed).

Method 3 — third-party server-management tools

If you already run a server-management layer, use its scheduler instead of rolling your own. Common options:

  • CSMM (CatalysmsServerManager / 7 Days to Die Server Manager) — has built-in scheduled commands, broadcast templates, and player-count-aware triggers. The recommended path if you want a UI.
  • BotMan — lighter-weight bot/scheduler, scriptable.
  • Server hosting panels (GTXGaming, Nitrado, BisectHosting, etc.) — most expose a "scheduled task" feature in the panel UI. Configure to run saveworld then shutdown on the cadence you want.

Whichever path you pick, the underlying sequence is identical: warn, save, shutdown, supervisor restarts.

How Often Should You Restart?

There's no universal answer — it depends on player load, mod set, and hardware. Reasonable starting points:

  • Vanilla, <8 players, modern hardware: every 24 h is plenty. Many servers go 48–72 h fine.
  • Vanilla, 8–16 players: every 12–24 h.
  • Heavy overhauls (Darkness Falls, Undead Legacy): every 6–12 h. Overhaul mods add entity types and persistent state that grow faster than vanilla.
  • Big modlet stack with custom UI/HUD: watch RAM trend over a week, set the timer just before the curve goes vertical.

If players are reporting rubber-banding or chunk-load stalls midway through a session, your cadence is too long. Shorten it before adding hardware.

Warnings & Common Mistakes

  • Don't kill -9 the server. Always go through shutdown (or systemctl stop on systemd, which sends SIGTERM and lets the server exit cleanly). Killing mid-write corrupts the chunk file.
  • Skipping saveworld can cost up to one auto-save interval of progress. The auto-save runs periodically; if shutdown happens right before the next one, players lose recent progress they thought was banked.
  • Restarting during Blood Moon is brutal. Make sure your scheduled time doesn't land on horde night (22:00–04:00 by default). A 04:00 restart cuts through the tail of every Blood Moon — pick a different hour or skip on Blood Moon days.
  • Telnet is plaintext. Don't expose port 8081 to the internet. Bind it to 127.0.0.1 only and SSH-tunnel for remote access.
  • Test your script once manually before enabling the timer. A typo in the telnet password or service name will silently fail every night.