This message appears when the SSH server you're connected to is shutting down or rebooting. The connection is abruptly closed by the remote system, usually due to scheduled maintenance, manual shutdown command, or system crash.
When an SSH-connected system is shutting down, the operating system broadcasts a shutdown message to all logged-in users (including those connected via SSH). This warning message is sent before the system actually goes offline. Unlike other SSH errors that indicate configuration or authentication problems, this message is informational—it means your connection is being forcefully closed because the remote system is going offline. The connection itself is fine; it's the remote host that's initiating the disconnection.
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.comOr 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 -100Look 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 --allLook 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.timerIf 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 --showIf 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 -20Stop 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.targetCreate 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)\"}"Advanced scenarios and troubleshooting:
OOM Killer on Kubernetes: If running in a Kubernetes cluster, the OOM killer may terminate a pod/node during high memory pressure. Check kubelet logs: journalctl -u kubelet -n 100 for eviction events.
Cloud Provider Scheduled Maintenance: AWS, Azure, GCP, and other cloud providers schedule maintenance windows. Check:
- AWS EC2: Status checks and scheduled events in the AWS console
- Azure: Planned maintenance notifications in the portal
- GCP: Maintenance notifications in Cloud Console
Database Connection Pool Exhaustion: On systems with active database connections, sudden shutdown can leave connections in CLOSE_WAIT state. Ensure proper connection cleanup in your application before attempting reconnection.
Load Balancer Behavior: If behind a load balancer, the LB may detect the shutdown and start routing traffic to healthy instances. Monitor LB health checks and metrics to confirm failover occurred.
Docker Container Shutdown: If the SSH server is running in a Docker container, the System is going down message usually comes from the init system inside the container (PID 1). Check the container logs: docker logs container-name to see what triggered shutdown.
Windows OpenSSH: Windows 10/Server 2019+ includes OpenSSH. System shutdown messages may differ; check Event Viewer instead of syslog.
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
How to fix SSH man-in-the-middle attack warning in SSH
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
How to fix "WARNING: UNPROTECTED PRIVATE KEY FILE!" in SSH
sign_and_send_pubkey: no mutual signature supported
How to fix "sign_and_send_pubkey: no mutual signature supported" in SSH
Bad owner or permissions on /home/user/.ssh/known_hosts
How to fix "Bad owner or permissions on known_hosts" in SSH
It is required that your private key files are NOT accessible by others.
How to fix "private key files are NOT accessible by others" in SSH