Quick answer: When a reboot does not fix it, stop rebooting — repeated restarts destroy evidence and can worsen filesystem damage. Move to structured diagnosis: watch the actual boot in the KVM Console, read what failed with journalctl -b, check disk/memory health, and if the OS is beyond repair, restore from backup or reinstall.
Overview
A reboot clears transient states (leaks, stuck processes) but cannot fix full disks, broken configs, corrupted filesystems or failing services with wrong settings. If the problem survives a restart, it is persistent — and persistent problems leave logs.
Before you start
- Client Area access (KVM Console) and, ideally, a recent backup you can restore.
Step-by-step guide
- Watch the boot in the KVM Console — errors during boot (failed mounts, fsck prompts, emergency mode) are invisible over SSH and name the culprit directly.
- Once booted, read this boot's log and failed units:
sudo journalctl -b -p err systemctl --failed - Check the two chronic causes:
Full disk or instant memory exhaustion re-breaks services right after every reboot.df -h free -h - Fix what the logs name: a service with a broken config will fail identically every boot until the config is corrected — restarting is not the fix, editing is.
- If the system is too damaged (corrupted packages, unbootable), decide between repair and rebuild: restoring from backup or reinstalling the OS from the service page is often faster and cleaner than archaeology.
- If compromise is suspected (unknown processes, strange traffic), switch to the incident guide — a reboot never cures a hacked server.
Common issues
- Emergency mode after reboot: usually a broken /etc/fstab entry — fix it in the console.
- Service "fixed" by reboot, breaks hours later: a leak or cron job — the journal shows the cycle.
- Reboot loop: stop, open the console, note the panic text, and include it in the ticket.
When to contact support
If the console shows errors that look hardware/platform-side, the VPS will not boot at all, or you need help deciding between repair and reinstall, open a ticket with the console screenshot and the journalctl -b -p err excerpt.
Frequently asked questions
Why do repeated reboots make things worse?
Each forced restart skips clean shutdown, risks further filesystem damage and erases the in-memory state that explains the fault. After one failed reboot, switch to reading logs and the console.
When is reinstalling faster than repairing?
When packages or the filesystem are corrupted and you have current backups: a clean OS from the service page plus a data restore is often done in an hour, with a known-good result.
Related articles
- My VPS is not responding
- How to restore a website from backup
- How to collect logs for support
- What to do if your server is hacked
Need a hand? Contact Cloud2Y support →
