How to fix Admin shutdown in PostgreSQL

PostgreSQLINTERMEDIATEMEDIUMUpdated Dec 28, 2025ยท 183 views

PostgreSQL admin shutdown (error code 57P01) occurs when an administrator or process initiates a server shutdown. This prevents new connections and terminates existing sessions, typically during maintenance or due to system signals.

Quick fix

Fixes Admin shutdown

# On Linux/macOS
tail -n 100 /var/log/postgresql/postgresql-<version>-main.log

# View logs in real-time during restart
tail -f /var/log/postgresql/postgresql-<version>-main.log
  1. Check if shutdown was planned
  2. Check PostgreSQL logs for shutdown reason
  3. Restart the PostgreSQL service
  4. Check system resources and logs
postgresql โ€” error
# On Linux/macOS
tail -n 100 /var/log/postgresql/postgresql-<version>-main.log
# View logs in real-time during restart
tail -f /var/log/postgresql/postgresql-<version>-main.log
Admin shutdown

What this error means

The "Admin shutdown" error indicates that the PostgreSQL server has received a shutdown command from an administrator or system process. This is usually triggered by a SIGTERM signal sent to the server postmaster process. When this error occurs, the database becomes unavailable and all client connections are terminated. This is a normal operational event during scheduled maintenance or restarts, but unexpected occurrences may indicate unplanned administrative intervention or system issues.

Typical symptoms

  • All database connections drop with "FATAL: Admin shutdown" message
  • New connection attempts fail immediately
  • Applications cannot reach the PostgreSQL server
  • Connection pools report all connections lost simultaneously
  • PostgreSQL service appears to be down or stopped

Common causes

  1. Scheduled maintenance or planned server restart by an administrator
  2. Manual shutdown via pg_ctl stop or systemctl stop postgresql
  3. SIGTERM signal sent to PostgreSQL postmaster process
  4. System reboot or container shutdown (in containerized environments)
  5. Resource exhaustion (disk space, memory) triggering automatic shutdown
  6. Health check or orchestration tool (Kubernetes, Docker) restarting the service
  7. Security policy or firewall changes affecting the server

How to fix "Admin shutdown"

1Check if shutdown was planned

Verify with your system administrator or DevOps team if this shutdown was intentional as part of scheduled maintenance. Check your maintenance calendar or recent tickets for any planned database work.

2Check PostgreSQL logs for shutdown reason

Review the PostgreSQL server logs to understand why the shutdown occurred:

bash
# On Linux/macOS
tail -n 100 /var/log/postgresql/postgresql-<version>-main.log

# View logs in real-time during restart
tail -f /var/log/postgresql/postgresql-<version>-main.log

Look for messages like "terminating connection due to administrator command" or crash-related entries.

3Restart the PostgreSQL service

If the shutdown was unplanned and the underlying issue has been resolved, restart the service:

bash
# Using systemctl (modern Linux)
sudo systemctl restart postgresql

# Using service (older systems)
sudo service postgresql restart

# Using pg_ctl directly
sudo -u postgres /usr/lib/postgresql/<version>/bin/pg_ctl -D /var/lib/postgresql/<version>/data start

Verify the service is running:

bash
sudo systemctl status postgresql
4Check system resources and logs

If the shutdown was unexpected, investigate system-level issues:

bash
# Check disk space
df -h

# Check memory availability
free -h

# Check system logs for OOM kills
sudo journalctl -xe
sudo dmesg | tail -20

If resources were exhausted, resolve the underlying capacity issues before restarting.

5Review recent configuration changes

Check if recent changes to PostgreSQL configuration may have triggered the shutdown:

bash
# Review postgresql.conf
sudo cat /var/lib/postgresql/<version>/data/postgresql.conf

# Check pg_hba.conf for authentication rule changes
sudo cat /var/lib/postgresql/<version>/data/pg_hba.conf

Revert any problematic configuration changes and retry the restart.

6Verify database consistency (if needed)

If the shutdown was sudden or unclean, PostgreSQL will perform crash recovery on startup. Monitor the logs during startup for recovery messages. If recovery fails, consider using pg_resetwal (only as a last resort with guidance from PostgreSQL community):

bash
# Let PostgreSQL handle recovery automatically on restart
# Do NOT manually intervene unless specifically advised

Advanced notes

In containerized environments (Docker, Kubernetes), admin shutdowns are often orchestrated by container runtimes or orchestrators. Check your container logs and orchestration platform logs. For rootless containers using systemd, enable linger to prevent automatic shutdown when the user logs out: loginctl enable-linger <username>. PostgreSQL supports three shutdown modes: smart (waits for connections), fast (aborts transactions), and immediate (force quit). The admin shutdown message typically results from a fast or immediate shutdown. If you see repeated unexpected shutdowns, implement monitoring with tools like Prometheus + pg_exporter to detect patterns.

Frequently asked questions

What does "Admin shutdown" mean?
The "Admin shutdown" error indicates that the PostgreSQL server has received a shutdown command from an administrator or system process. This is usually triggered by a SIGTERM signal sent to the server postmaster process. When this error occurs, the database becomes unavailable and all client connections are terminated.
How do I fix "Admin shutdown"?
PostgreSQL admin shutdown (error code 57P01) occurs when an administrator or process initiates a server shutdown. This prevents new connections and terminates existing sessions, typically during maintenance or due to system signals.
What causes "Admin shutdown"?
Scheduled maintenance or planned server restart by an administrator Manual shutdown via pg_ctl stop or systemctl stop postgresql SIGTERM signal sent to PostgreSQL postmaster process
Is the "Admin shutdown" error serious?
It is a medium-severity error โ€” more of a blocker than a risk. The steps above resolve it.

Official resources & further reading