How to fix Lock file exists in PostgreSQL

PostgreSQLINTERMEDIATEHIGHUpdated Dec 28, 2025· 250 views

PostgreSQL fails to start because the postmaster.pid lock file exists in the data directory, indicating a previous instance did not shut down cleanly. Remove the stale lock file after verifying no PostgreSQL processes are running.

Quick fix

Fixes Lock file exists

# Check if the PID from the error is actually running
ps aux | grep <PID_FROM_ERROR>

# Or check all PostgreSQL processes
ps aux | grep postgres
  1. Verify no PostgreSQL process is actually running
  2. Locate the data directory and lock file
  3. Remove the stale lock file
  4. Restart PostgreSQL
postgresql — error
# Check if the PID from the error is actually running
ps aux | grep <PID_FROM_ERROR>
# Or check all PostgreSQL processes
ps aux | grep postgres
Lock file exists

What this error means

PostgreSQL uses a postmaster.pid lock file in its data directory to track active server instances. This file is created when PostgreSQL starts and removed during normal shutdown. When PostgreSQL encounters an existing lock file, it assumes another instance is already running and refuses to start. This error occurs when a PostgreSQL instance crashes, loses power, or terminates abnormally without removing the lock file. The error manifests as "FATAL: lock file "postmaster.pid" already exists" with a hint about whether another postmaster (and its PID) is running.

Typical symptoms

  • PostgreSQL service fails to start with "FATAL: lock file postmaster.pid already exists"
  • Error message includes a PID hint: "Is another postmaster (PID XXX) running in data directory..."
  • PostgreSQL was not running when you tried to restart it
  • PostgreSQL crashed, lost power, or was forcefully terminated
  • systemctl status postgresql shows inactive status

Common causes

  1. PostgreSQL crashed or was forcefully terminated without removing the lock file
  2. System lost power while PostgreSQL was starting up
  3. Server restarted while PostgreSQL was in the middle of initializing
  4. A PostgreSQL process hung and did not shut down cleanly
  5. Incorrect manual shutdown (using kill -9 instead of proper pg_ctl stop)

How to fix "Lock file exists"

1Verify no PostgreSQL process is actually running

First, confirm that PostgreSQL is not running. Check the PID mentioned in the error message.

bash
# Check if the PID from the error is actually running
ps aux | grep <PID_FROM_ERROR>

# Or check all PostgreSQL processes
ps aux | grep postgres

If no PostgreSQL processes appear, proceed to the next step. If a process is running, you must stop it properly before removing the lock file.

2Locate the data directory and lock file

Find where PostgreSQL stores its data. The lock file is always located in the root of the data directory as postmaster.pid.

bash
# Common PostgreSQL data directory locations:
# Linux (Debian/Ubuntu)
/var/lib/postgresql/<version>/main/postmaster.pid

# Linux (Red Hat/CentOS/Fedora)
/var/lib/pgsql/data/postmaster.pid

# macOS
/usr/local/var/postgres/postmaster.pid

# Windows
C:\Program Files\PostgreSQL\<version>\data\postmaster.pid

Verify the lock file exists:

bash
ls -la /var/lib/postgresql/13/main/postmaster.pid
3Remove the stale lock file

Once you have confirmed no PostgreSQL process is running, remove the lock file:

bash
# Linux/macOS (use sudo if necessary)
rm /var/lib/postgresql/<version>/main/postmaster.pid

# Or more safely, check permissions first
ls -l /var/lib/postgresql/<version>/main/postmaster.pid
sudo rm /var/lib/postgresql/<version>/main/postmaster.pid

Important: Only remove this file if you are certain no PostgreSQL process is running. Deleting postmaster.pid while PostgreSQL is active can cause severe data corruption.

4Restart PostgreSQL

After removing the stale lock file, restart PostgreSQL:

bash
# Linux with systemd
sudo systemctl restart postgresql

# Linux with service command
sudo service postgresql restart

# macOS with Homebrew
brew services restart postgresql

# Manual startup (if using non-standard installation)
pg_ctl -D /path/to/data/directory start

Verify PostgreSQL is running:

bash
# Check service status
sudo systemctl status postgresql

# Or test connection
psql -U postgres -c "SELECT version();"

Advanced notes

The postmaster.pid file contains exactly eight lines of information including the postmaster process ID, the data directory path, the start time, and shared memory segment information. If the file is empty or corrupted, it indicates an incomplete startup sequence, often due to unclean shutdown. On Windows, pg_ctl may timeout during startup cleanup on the first boot after reboot, leaving an orphaned postgres.exe process and an incomplete lock file. In this case, manually kill the process and remove the lock file. When PostgreSQL is running on multiple machines accessing the same data directory (NFS mount, distributed storage), ensure only one instance can start at a time using filesystem locks or clustering software. If you frequently encounter this error, investigate why PostgreSQL is not shutting down cleanly—this may indicate resource constraints, hung queries, or misconfigured shutdown timeouts.

Frequently asked questions

What does "Lock file exists" mean?
pid lock file in its data directory to track active server instances. This file is created when PostgreSQL starts and removed during normal shutdown. When PostgreSQL encounters an existing lock file, it assumes another instance is already running and refuses to start.
How do I fix "Lock file exists"?
PostgreSQL fails to start because the postmaster.pid lock file exists in the data directory, indicating a previous instance did not shut down cleanly. Remove the stale lock file after verifying no PostgreSQL processes are running.
What causes "Lock file exists"?
PostgreSQL crashed or was forcefully terminated without removing the lock file System lost power while PostgreSQL was starting up Server restarted while PostgreSQL was in the middle of initializing
Is the "Lock file exists" error serious?
Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.

Official resources & further reading