How to fix System is going down. Disconnected. in SSH

The 'System is going down' message is not an error in the traditional sense—it's a broadcast notification. The remote system administrator (or automated process) has initiated a shutdown sequence. There is nothing you can do on your local machine to prevent it.

Your SSH session will terminate within seconds. Accept that the connection is ending and plan accordingly.

If this is a scheduled reboot (maintenance window), the server will typically return online within minutes to an hour. You can check connectivity with:

ping hostname.example.com

Or check SSH availability:

ssh -v [email protected]

Keep polling until the server responds. This indicates the shutdown has completed and services are restarting.

Once the server is back online, SSH in and check system logs to identify why the shutdown happened:

# View reboot history
last | head -5

# Check system messages log
sudo tail -50 /var/log/syslog

# On Red Hat/CentOS/Fedora
sudo tail -50 /var/log/messages

# Using journalctl (systemd systems)
sudo journalctl -u reboot.service -n 20
sudo journalctl --since "30 minutes ago" | tail -100

Look for lines like:
- "Shutdown initiated by user X"
- "OOM killer invoked"
- "Out of memory"
- "System halted"
- "Kernel panic"

Determine if shutdown was scheduled. Check cron jobs:

# View system cron jobs
sudo crontab -l

# Check all user cron jobs
for user in $(cut -f1 -d: /etc/passwd); do crontab -u $user -l 2>/dev/null; done

# Check systemd timers
sudo systemctl list-timers --all

Look for entries that include shutdown, reboot, halt, or poweroff.

If you find a scheduled shutdown and it wasn't intended, disable it:

# Disable specific cron job (if found)
sudo crontab -e  # Remove the line, save and exit

# Or stop a systemd timer
sudo systemctl disable timer-name.timer
sudo systemctl stop timer-name.timer

If the shutdown wasn't intentional or scheduled, check if the system ran out of memory:

# Check current memory usage
free -h

# Check OOM killer logs
dmesg | grep -i "oom-kill" | tail -10

# Check if swap is configured
swapon --show

If OOM killer was triggered, you have two options:

1. Increase available memory: Add more RAM to the instance or resize to a larger instance type.

2. Reduce memory usage: Identify which processes consume excessive memory:

ps aux --sort=-%mem | head -20

Stop unnecessary services or optimize memory-heavy applications.

To be notified when the system is shutting down (instead of being surprised by disconnect), monitor for shutdown signals:

# Watch journalctl for shutdown messages in real-time
sudo journalctl -f | grep -i "shutdown\|halt\|poweroff"

# Or use watch-systemd-units if available
watch "sudo systemctl status"

For production servers, configure monitoring:
- Set up system log aggregation (ELK, Splunk, etc.) to alert on shutdown events
- Use cloud provider monitoring (CloudWatch, Azure Monitor, GCP Monitoring) to detect instance restarts
- Configure email or Slack notifications for critical system events

Example with systemd service for graceful shutdown handling:

[Unit]
Description=Graceful Shutdown Handler
Before=shutdown.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/notify-shutdown.sh
RemainAfterExit=yes

[Install]
WantedBy=shutdown.target

Create the notification script at /usr/local/bin/notify-shutdown.sh:

#!/bin/bash
curl -X POST https://your-webhook.example.com/shutdown \
  -H "Content-Type: application/json" \
  -d "{\"host\": \"$(hostname)\", \"timestamp\": \"$(date)\"}"