VPS Keeps Rebooting: Fix Unexpected Restart Loop on Linux Server

An unexpected or repeated VPS reboot is disruptive and dangerous for running services. The most important thing is to read the crash evidence before it scrolls away. Here is how to diagnose and stop a reboot loop.

Step 1: Find Out Why It Rebooted

The moment you're back in, check:

# Reason for last shutdown/reboot
last reboot | head -5

# Kernel ring buffer from before the crash (if kdump is configured)
journalctl -k -b -1 | tail -60

# System logs around the time of the reboot
journalctl --since "30 min ago" | grep -i -E "panic|oom|killed|error|reboot"

Also look at /var/log/syslog or /var/log/messages for entries just before the reboot timestamp.

Common Causes and Fixes

OOM Killer (Out of Memory)

The most frequent cause on low-RAM VPS instances. When RAM is exhausted, the kernel kills the process with the highest OOM score to free memory — then sometimes the killed process was critical enough that systemd triggers a reboot.

Confirm:

journalctl -k | grep -i "out of memory\|oom\|killed process"

Fix:

# Add a swap file immediately
fallocate -l 2G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
echo '/swapfile none swap sw 0 0' >> /etc/fstab

# Check current memory usage
free -h

Lower the OOM score of critical processes you don't want killed:

# Example: protect nginx
echo -1000 > /proc/$(pgrep nginx | head -1)/oom_score_adj

Kernel Panic

A kernel panic is a fatal error the kernel cannot recover from. On VPS, this is rare but can happen after a bad kernel update or storage I/O error.

Confirm:

journalctl -k -b -1 | grep -i panic

If a kernel panic loop occurs after an update, boot into the previous kernel from GRUB:

Access the VNC console via VMHeaven's control panel
Hold/press Esc or Shift during boot to get the GRUB menu
Select Advanced options → choose the previous kernel version
Once booted: apt-mark hold linux-image-$(uname -r) to prevent re-upgrade

Systemd Unit Configured to Reboot on Failure

A service restart policy set to always with RestartSec=0 and a OnFailure=reboot.target can cause reboot loops.

# Find units that trigger reboot on failure
grep -r "OnFailure=reboot" /etc/systemd/system/
grep -r "FailureAction=reboot" /etc/systemd/system/

Edit the offending unit file and remove or change the OnFailure / FailureAction line, then:

systemctl daemon-reload

Unclean Filesystem Causing fsck Loop

If the filesystem was not cleanly unmounted, the system runs fsck on boot. If fsck finds unfixable errors, it may reboot repeatedly.

Fix via rescue mode:

Boot into rescue via VMHeaven control panel
Run: fsck -y /dev/vda1 (replace with your root partition)
Reboot normally after fsck completes

Watchdog Timer Triggering Reboots

Some VPS configurations have a software watchdog that reboots the system if it does not receive a heartbeat within a set time — this can fire if the system is under extreme CPU load.

# Check if watchdog is active
cat /proc/sys/kernel/watchdog
systemctl status watchdog 2>/dev/null

Disable if not needed:

systemctl stop watchdog
systemctl disable watchdog

Step 2: Prevent Future Unplanned Reboots

Disable automatic reboot on kernel panic (useful for diagnosing — not for production):

# In /etc/sysctl.d/99-panic.conf
kernel.panic = 0
sysctl --system

Set kernel.panic > 0 to allow a reboot after N seconds if a panic is unavoidable but you want eventual recovery:

# Reboot 10 seconds after a kernel panic
echo 'kernel.panic = 10' >> /etc/sysctl.d/99-panic.conf
sysctl --system

Monitor memory proactively:

# Alert when RAM drops below 10%
free -m | awk '/Mem:/ { if ($4/$2*100 < 10) print "Low RAM: " $4 "MB free" }'

Enable kdump to capture a crash dump before reboot (Debian/Ubuntu):

apt install -y kdump-tools crash

Crash dumps are saved to /var/crash/ and can be analyzed with the crash utility to identify the exact cause of a kernel panic.

Step 3: Contact Support if Hardware-Level

If none of the above explains the reboots, the issue may be at the hypervisor or hardware layer (bad RAM, failing disk, node migration). Open a support ticket with VMHeaven and include:

The exact timestamps of each reboot (from last reboot)
Output of journalctl -k -b -1 | tail -80
Any error messages from the VNC console during the restart

VMHeaven support can check the hypervisor event log for your instance to identify host-side issues.

All fixes