How to Resolve "PostgreSQL Database System Is Shutting Down" Startup Error

Connections to PostgreSQL fail with a message saying the database system is shutting down, even though you didn't intentionally stop it. This message means PostgreSQL is in the middle of a shutdown sequence — the real question is what triggered it, since this could be anything from a normal admin action to a crash recovery in progress.

The Problem

Every connection attempt fails with the same terse message:

$ psql -U app_user -d mydb
psql: error: FATAL:  the database system is shutting down

Application logs show the same underlying error surfacing through the driver:

FATAL: the database system is shutting down
SQLSTATE[57P03]

Why It Happens

PostgreSQL only shows this message while genuinely in a shutdown or restart sequence — it's not a permissions error or a misconfiguration, it's PostgreSQL accurately reporting its own current state. What triggered that state varies:

• An intentional restart or stop — someone ran systemctl restart postgresql, a deployment script restarted the service, or a scheduled maintenance window is in progress.
• An out-of-memory kill — the Linux OOM killer terminated the PostgreSQL postmaster process, triggering an automatic shutdown of all backend processes as a safety measure.
• A crash requiring recovery — after an unclean termination (power loss, forced kill), PostgreSQL goes through WAL-based crash recovery on the next startup, and connections are refused until that recovery completes.
• Disk space exhaustion — PostgreSQL can trigger a shutdown-like state if it can't write to its data directory or WAL files due to a full disk.
• A configuration change requiring a restart was applied, and the service is mid-restart as part of that change taking effect.

The Fix

Check whether PostgreSQL is actually running right now:

sudo systemctl status postgresql

● postgresql.service - PostgreSQL RDBMS
     Loaded: loaded
     Active: activating (start-post) since Thu 2026-08-07 09:00:12 UTC

If it shows activating or deactivating, it's mid-transition — check the actual PostgreSQL log for what's happening during that window, which usually explains exactly what's going on:

sudo tail -50 /var/log/postgresql/postgresql-16-main.log

LOG:  database system was interrupted; last known up at 2026-08-07 08:55:03 UTC
LOG:  database system was not properly shut down; automatic recovery in progress
LOG:  redo starts at 2/3A8B2E10
LOG:  redo done at 2/3A9F1120

If you see "automatic recovery in progress," this is normal crash recovery — PostgreSQL is replaying its write-ahead log to restore a consistent state, and connections will resume automatically once recovery finishes. The duration depends on how much unwritten data existed at the time of the crash; wait and monitor rather than intervening:

watch -n 2 "sudo systemctl status postgresql | grep Active"

If the log instead shows an out-of-memory kill or a crash, check dmesg to confirm and understand the underlying cause before just restarting and hoping it doesn't happen again:

dmesg | grep -i "out of memory\|killed process" | tail -10

If disk space is the trigger, free up space immediately, since PostgreSQL cannot safely operate — or even complete recovery — without room to write:

df -h /var/lib/postgresql

sudo find /var/log/postgresql -name "*.log" -mtime +30 -delete

Still Not Working?

If PostgreSQL seems permanently stuck in a shutdown or recovering state rather than progressing, check for a stale lock file or postmaster PID file left over from an especially abrupt termination, which can sometimes prevent a clean restart:

ls -la /var/lib/postgresql/16/main/postmaster.pid

If PostgreSQL is confirmed not running (no matching process for the PID in that file) but the file still exists, it's safe to remove it manually before attempting to start PostgreSQL again — but only after confirming via ps that no postgres process is actually still alive, since removing this file while PostgreSQL is genuinely running can cause serious corruption:

ps aux | grep postgres
sudo rm /var/lib/postgresql/16/main/postmaster.pid
sudo systemctl start postgresql

After a crash-triggered recovery of any kind, it's worth reviewing your monitoring and alerting to catch the underlying cause (memory pressure, disk space, unexpected restarts) proactively next time, rather than discovering it reactively through a wave of failed application connections.