I just reinstalled postgres via brew install postgres

I ran initdb /usr/local/var/postgres -E utf8 but got this:

The files belonging to this database system will be owned by user "atal421".
This user must also own the server process.

The database cluster will be initialized with locale "en_US.UTF-8".
The default text search configuration will be set to "english".

initdb: directory "/usr/local/var/postgres" exists but is not empty
If you want to create a new database system, either remove or empty
the directory "/usr/local/var/postgres" or run initdb
with an argument other than "/usr/local/var/postgres".

so, I rm -rf the postgres folder and ran it again:

 initdb /usr/local/var/postgres -E utf8

it said everything was okay:

Success. You can now start the database server using:

    postgres -D /usr/local/var/postgres

so, I ran that command and got:

postgres -D /usr/local/var/postgres

FATAL:  lock file "postmaster.pid" already exists
HINT:  Is another postmaster (PID 13731) running in data directory "/usr/local/var/postgres"?

Now when I look at my Activity Monitor I can see 6 instances of postgress.

How do I fix this?

  • You probably see one instance of postgres with a postmaster and five utility backends. PostgreSQL is a multi-process architecture. Feb 17, 2013 at 23:39

8 Answers 8


Public service announcement: never delete postmaster.pid. Really. Great way to get data corruption.

You already had PostgreSQL installed, and you deleted the data dir without stopping the running server. So you now have some orphan PostgreSQL server processes that are managing data files that've been deleted, so they're no longer accessible in the file system and will be fully deleted when the last open file handle to them is closed. You can't use pg_ctl to shut the server down like normal because you've deleted the cluster datadir, so you must simply kill the processes. Kill the postmaster (do not use kill -9, just an ordinary kill will do) and the rest will shut down too.

You will then be able to start a new server in the datadir against the freshly initdb'd data.

It is highly likely that you will experience conflicts down the track unless you uninstall the other older version of PostgreSQL.

In a nutshell:

cat /usr/local/var/postgres/postmaster.pid

Note down the number on the first line, which is the pid of the postmaster.

Verify with ps that the pid is that of a postgres postmaster.

Kill the postmaster process with the following command, replacing 'PID' with the number you have noted down. Again, do not use kill -9 or kill -KILL, just use a plain kill, i.e. a SIGTERM:

kill PID

If the pid is not that of a postgres postmaster, manually kill any postgres backends that may still be running, verify that they are no longer running, and only then remove postmaster.pid. (You must also verify that the postmaster.pid is not on shared storage where the server could be running on some other VM/host).

  • this worked for me!
    – Tone
    Nov 26, 2013 at 6:53
  • This works. Had a problem where I emptied my trash and it seems some data files probably were in there...not sure how, but they were. Once I killed the old process it worked fine.
    – Dan L
    Jun 4, 2014 at 15:30
  • yeah. that was spot on. Jun 2, 2015 at 15:52
  • 10
    It should be mentioned that after a hard crash the PID file might survive, while the process dies. In that case the PID in the PID file can point to a process that's got nothing to do with Postgres. See second answer for that case.
    – febeling
    May 31, 2016 at 11:46
  • 2
    A plain kill PID didn't work for me. I needed kill -3 PID. In my case I had done a shutdown which may have killed terminal windows without stopping the processes properly. The kill -3 PID killed the process and its children successfully letting me start postgres again. Jun 26, 2017 at 8:31

Another possibility is that you had a hard shutdown and the postgres process died without cleaning up its pid file. This happens to me when my laptop's battery dies.

This solution is not for a production system, and you should really make sure the postgres daemon is not running, but I use my laptop for coding and I'm not worried about needing to regenerate my databases.

So if another process -- or none at all -- is running on that port, just delete the pid file, e.g.

rm /usr/local/var/postgres/postmaster.pid

and postgres will soon start up fine.

To find out if another process is running on that port, you can do

ps wax | grep `head -1 /usr/local/var/postgres/postmaster.pid`

Then run

tail -f /usr/local/var/postgres/server.log 

to see if it worked. You should see

FATAL:  lock file "postmaster.pid" already exists
HINT:  Is another postmaster (PID 933) running in data directory "/usr/local/var/postgres"?
FATAL:  lock file "postmaster.pid" already exists
HINT:  Is another postmaster (PID 933) running in data directory "/usr/local/var/postgres"?
LOG:  database system was interrupted; last known up at 2014-05-25 09:41:32 PDT
LOG:  database system was not properly shut down; automatic recovery in progress

(or at least that's what I just saw after I did the above :-) )

(And really, shouldn't Postgres be smart enough to realize that there is no process with PID 933 and remove the bogus pid file on its own?)

  • 1
    This was the case for me. I had another process coincidentally running on the same PID as the postmaster.pid file was pointing to. This was several days after an unclean shutdown (laptop installation of Postgres on OSX via homebrew). Oct 7, 2014 at 3:04
  • 1
    My mac hung on the login screen and I had to power it down. That ended up leaving a postmaster.pid file around that referenced a PID which got used for something else on the next reboot and postgres wouldn't come up. I tried killing the PID (like the post by craig-ringer recommended), but that didn't help. However, rm postmaster.pid worked for me. I don't see any data corruption (but in any case, this is just a development machine). Jan 25, 2016 at 16:43
  • Same thing for me. I had shut down my mac without stopping the local Rails server. Jun 20, 2016 at 19:47
  • 1
    I keep coming back to this thread whenever this happens - because I can never remember where the pid file is, so I always have to look it up :P
    – haslo
    Apr 20, 2017 at 12:55
  • This happened to me with the Postgres.app. After deleting ~/Library/Application Support/Postgres/data/postmaster.pid I was up and running again. Sep 23, 2017 at 2:21

I tried all of this to no avail after upgrading to Yosemite broke my postgres (installed via homebrew).

Then I stumbled on this blog post: http://ruckus.tumblr.com/post/100355276496/yosemite-upgrade-breaks-homebrew-installed-postgres

First I needed to create the missing directories that were apparently wiped out during the upgrade (thanks Apple!).

$ cd /usr/local/var/postgres

$ mkdir {pg_tblspc,pg_twophase,pg_stat_tmp}

Then just start postgres again using the normal homebrew launch sequence:

$ launchctl unload ~/Library/LaunchAgents/homebrew.mxcl.postgresql.plist

$ launchctl load ~/Library/LaunchAgents/homebrew.mxcl.postgresql.plist

Thanks Ruckus Notes for helping solve my problem. Hopefully it helps you as well.



I had this same issue after a hard reboot. After checking the postmaster.pid file's pid, I noticed I had no process running. I didn't want to hard delete the .pid file, instead I used a pg-stop alias I had created in my .bash_profile. this alias just runs

pg_ctl -D /usr/local/var/postgres stop -s -m fast

For Reference

# psql
alias pg-start='pg_ctl -D /usr/local/var/postgres -l /usr/local/var/postgres/server.log start'
alias pg-stop='pg_ctl -D /usr/local/var/postgres stop -s -m fast'

log output after pg-stop

LOG:  database system was interrupted; last known up at 2016-04-25 10:51:08 PDT
LOG:  database system was not properly shut down; automatic recovery in progress
LOG:  record with zero length at 0/274FA10
LOG:  redo is not required
LOG:  database system is ready to accept connections
LOG:  autovacuum launcher started
LOG:  received smart shutdown request
LOG:  autovacuum launcher shutting down
LOG:  shutting down
LOG:  database system is shut down
LOG:  database system was shut down at 2016-04-25 13:11:04 PDT


I thought I should also mention here that if you have installed postgres with homebrew you should give brew services a look. That is now how I prefer to start/stop my databases.

XXXXX:~ chris$ brew services list
Name       Status  User  Plist
mongodb    stopped
postgresql started chris /Users/chris/Library/LaunchAgents/homebrew.mxcl.postgresql.plist
redis      started chris /Users/chris/Library/LaunchAgents/homebrew.mxcl.redis.plist
  • Thanks it worked! 🙌
    – kaxi1993
    Sep 26, 2021 at 18:23

Deleting postmaster.pid is actually a really decent thing to do at every boot, blindly. That's what my system does. Because you've just booted up, you know there is no Postgres process running, and if you're recovering from an unclean shutdown, this file will be there preventing your recovery.

A better design for Postgres would be to put the postmaster.pid file in the /run filesystem, so it is guaranteed to get deleted at every reboot. Many other servers work that way.


I received this error after, I think, my computer crashed. PostgreSQL couldn't even start because of this error so killing the process wasn't the solution. I simply backed-up and then deleted the postmaster.pid file and then the error stopped and PG was able to start again.


Sometimes the humble pg_ctl -w restart can do the trick :-)

  • Love when the top answer is YOU ARE DOOMED! TOUCH NOTHING! and then one little command gets me running. (In my case the pid in /usr/pgsql/9.3/data/postmaster.pid was not present in ps aux.)
    – Noumenon
    May 8, 2018 at 14:50

I fixed this by doing brew services stop postgresql -- I was doing this on Mac.

I could then start as usual, using either homebrew or manually.

My guess is that pg_ctl -D /usr/local/var/postgres and brew services start create different record files, and you need to start the same way you start.

Good luck.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.