Ask Ubuntu is a question and answer site for Ubuntu users and developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I installed the Bitnami Django stack which included PostgreSQL 8.4.

When I run psql -U postgres I get the following error:

psql: could not connect to server: No such file or directory
    Is the server running locally and accepting
    connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?

PG is definitely running and the pg_hba.conf file looks like this:

# TYPE  DATABASE        USER            CIDR-ADDRESS            METHOD

# "local" is for Unix domain socket connections only
local   all             all                                     md5
# IPv4 local connections:
host    all             all               md5
# IPv6 local connections:
host    all             all             ::1/128                 md5

What gives?

"Proof" that pg is running:

root@assaf-desktop:/home/assaf# ps axf | grep postgres
14338 ?        S      0:00 /opt/djangostack-1.3-0/postgresql/bin/postgres -D /opt/djangostack-1.3-0/postgresql/data -p 5432
14347 ?        Ss     0:00  \_ postgres: writer process                                                                        
14348 ?        Ss     0:00  \_ postgres: wal writer process                                                                    
14349 ?        Ss     0:00  \_ postgres: autovacuum launcher process                                                           
14350 ?        Ss     0:00  \_ postgres: stats collector process                                                               
15139 pts/1    S+     0:00              \_ grep --color=auto postgres
root@assaf-desktop:/home/assaf# netstat -nltp | grep 5432
tcp        0      0*               LISTEN      14338/postgres  
tcp6       0      0 ::1:5432                :::*                    LISTEN      14338/postgres  
share|improve this question

11 Answers 11

This issue comes from installing the postgres package with out a version number. Although postgres will be installed and it will be the correct version, the script to setup the cluster will not run correctly; it's a packaging issue.

If you're comfortable with postgres there is a script you can run to create this cluster and get postgres running however there's an easier way.

First purge the old postgres install. The issue currently lies with 9.1 so I will assume that's what you have installed

sudo apt-get remove --purge postgresql-9.1

Now simply reinstall

sudo apt-get install postgresql-9.1

Note the package name with the version number. HTH.

share|improve this answer
this helped me with postgres 9.3. – sevenseacat Jul 30 '14 at 1:49
Wow. How did you figure this out? This answer helped me with version 9.3. – alejoss Mar 24 '15 at 22:41
This should be the accepted answer, works with postgres 9.4 / ubuntu 14.10, too – Malte Apr 8 '15 at 10:09
works for me with Ubuntu 12.04 – D4r7h Apr 11 '15 at 11:16
works for me too with Ubuntu 12.04 postgres 9.3 – Dimas Ari Dec 2 '15 at 22:13

The error message refers to a Unix-domain socket, so you need to tweak your netstat invocation to not exclude them. So try it without the option -t:

netstat -nlp | grep 5432

I would guess that the server is actually listening on the socket /tmp/.s.PGSQL.5432 rather than the /var/run/postgresql/.s.PGSQL.5432 that your client is attempting to connect to. This is a typical problem when using hand-compiled or third-party PostgreSQL packages on Debian or Ubuntu, because the source default for the Unix-domain socket directory is /tmp but the Debian packaging changes it to /var/run/postgresql.

Possible workarounds:

  • Use the clients supplied by your third-party package (call /opt/djangostack-1.3-0/postgresql/bin/psql). Possibly uninstall the Ubuntu-supplied packages altogether (might be difficult because of other reverse dependencies).
  • Fix the socket directory of the third-party package to be compatible with Debian/Ubuntu.
  • Use -H localhost to connect via TCP/IP instead.
  • Use -h /tmp or equivalent PGHOST setting to point to the right directory.
  • Don't use third-party packages.
share|improve this answer

You can use psql -U postgres -h localhost to force the connection to happen over TCP instead of UNIX domain sockets; your netstat output shows that the PostgreSQL server is listening on localhost's port 5432.

You can find out which local UNIX socket is used by the PostgrSQL server by using a different invocavtion of netstat:

netstat -lp --protocol=unix | grep postgres

At any rate, the interfaces on which the PostgreSQL server listens to are configured in postgresql.conf.

share|improve this answer

Just create a softlink like this :

ln -s /tmp/.s.PGSQL.5432 /var/run/postgresql/.s.PGSQL.5432
share|improve this answer
This worked for me and seemed to be the easiest solution without having to change your postgresql configuration. Be sure that you are superuser when trying to make link. – brendan Mar 7 '13 at 20:11

I had to compile PostgreSQL 8.1 on Debian Squeeze because I am using Project Open, which is based on OpenACS and will not run on more recent versions of PostgreSQL.

The default compile configuration puts the unix_socket in /tmp, but Project Open, which relies on PostgreSQL, would not work because it looks for the unix_socket at /var/run/postgresql.

There is a setting in postgresql.conf to set the location of the socket. My problem was that either I could set for /tmp and psql worked, but not project open, or I could set it for /var/run/postgresql and psql would not work but project open did.

One resolution to the issue is to set the socket for /var/run/postgresql and then run psql, based on Peter's suggestion, as:

psql -h /var/run/postgresql

This runs locally using local permissions. The only drawback is that it is more typing than simply "psql".

The other suggestion that someone made was to create a symbolic link between the two locations. This also worked, but, the link disappeared upon reboot. It maybe easier to just use the -h argument, however, I created the symbolic link from within the PostgreSQL script in /etc/init.d. I placed the symbolic link create command in the "start" section. Of course, when I issue a stop and start or restart command, it will try to recreate an existing symbolic link, but other than warning message, there is probably no harm in that.

In my case, instead of:

ln -s /tmp/.s.PGSQL.5432 /var/run/postgresql/.s.PGSQL.5432

I have

ln -s /var/run/postgresql/.s.PGSQL.5432 /tmp/.s.PGSQL.5432

and have explicitly set the unix_socket to /var/run/postgresql/.s.PGSQL.5432 in postgresql.conf.

share|improve this answer

It works for me:

Edit: postgresql.conf

sudo nano /etc/postgresql/9.3/main/postgresql.conf

Enable or add:

listen_addresses = '*'

Restart the database engine:

sudo service postgresql restart

Besides, you can check the file: pg_hba.conf

sudo nano /etc/postgresql/9.3/main/pg_hba.conf

And add your network or host address:

host all all md5

share|improve this answer
the listen_address = '*' made the trick. it was only listening on "localhost" and not on thank you! – mwm Jun 25 '15 at 23:06


Do this

export LC_ALL="en_US.UTF-8"

and this. (9.3 is my current PostgreSQL version. Write your version!)

sudo pg_createcluster 9.3 main --start
share|improve this answer
woooow, it was the only solving my problem, thanks . – user3687723 Jul 17 at 22:25

While having the same issue I tried something different:

starting manually postgresql daemon I got:

FATAL: could not create shared memory segment ... To reduce the request size (currently 57237504 bytes), reduce PostgreSQL's shared memory usage, perhaps by reducing shared_buffers or max_connections.

so what I did was to set a lower limit for shared_buffers and max_connections into postgresql.conf and restart the service.

This fixed!

PS: follows complete error log

$ sudo service postgresql start
 * Starting PostgreSQL 9.1 database server                                                                                                                                                               * The PostgreSQL server failed to start. Please check the log output:
2013-06-26 15:05:11 CEST FATAL:  could not create shared memory segment: Invalid argument
2013-06-26 15:05:11 CEST DETAIL:  Failed system call was shmget(key=5432001, size=57237504, 03600).
2013-06-26 15:05:11 CEST HINT:  This error usually means that PostgreSQL's request for a shared memory segment exceeded your kernel's SHMMAX parameter.  You can either reduce the request size or reconfigure the kernel with larger SHMMAX.  To reduce the request size (currently 57237504 bytes), reduce PostgreSQL's shared memory usage, perhaps by reducing shared_buffers or max_connections.
    If the request size is already small, it's possible that it is less than your kernel's SHMMIN parameter, in which case raising the request size or reconfiguring SHMMIN is called for.
    The PostgreSQL documentation contains more information about shared memory configuration.
share|improve this answer

Possibly it could happened because you changed permission of /var/lib/postgresql/9.3/main folder. try changing it to 700 using command bellow:

sudo chmod 700 main
share|improve this answer

I had the exact same problem Peter Eisentraut described. Using the netstat -nlp | grep 5432 command, I could see the server was listening on socket /tmp/.s.PGSQL.5432.

To fix this, just edit your postgresql.conf file and change the following lines:

listen_addresses = '*'
unix_socket_directories = '/var/run/postgresql'

Now run service postgresql-9.4 restart (Replace 9-4 with your version), and remote connections should be working now.

Now to allow local connections, simply create a symbolic link to the /var/run/postgresql directory.

ln -s /var/run/postgresql/.s.PGSQL.5432 /tmp/.s.PGSQL.5432

Don't forget to make sure your pg_hba.conf is correctly configured too.

share|improve this answer

I have tried all the above, untill I followed to the letter the following.

Yes I had the same problem. (using Ubuntu 15.10 (wily)) A sudo find / -name 'pg_hba.conf' -print or sudo find / -name 'postgresql.conf' -print turned up empty. Before that it seemed that multiple instances of postgresql were installed.

You might have simular when you see as installed, or dependency problems listing

.../postgresql .../postgresql-9.x and so on.

In that case you must sudo apt-get autoremove (each package 1 by 1)

Then following this to the letter and you will be fine. Especially when it comes to key importing and adding to source list FIRST

sudo apt-get update && sudo apt-get -y install python-software-properties && wget --quiet -O - | sudo apt-key add -

if not using wily change wily into your release. (output of lsb_release -c)

sudo sh -c 'echo "deb wily-pgdg main" >> /etc/apt/sources.list.d/postgresql.list'

sudo apt-get update && sudo apt-get install postgresql-9.3 pgadmin3

END --

And then you should be fine and be able to connect and create users.


  Creating new cluster 9.3/main ...
  config /etc/postgresql/9.3/main
  data   /var/lib/postgresql/9.3/main
  locale en_US.UTF-8
  socket /var/run/postgresql
  port   5432

source of my solutions (credits)

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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