I typed psql and I get this:
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"?
I used sudo netstat -nlp | grep 5432 to see the status but nothing showed.
And I searched online, somebody told me to modify pg_hba.conf but I can't locate this file. And I also tried this command sudo ln -s /tmp/.s.PGSQL.5432 /var/run/postgresql/.s.PGSQL.5432. It can't work.
The error states that the psql utility can't find the socket to connect to your database server. Either you don't have the database service running in the background, or the socket is located elsewhere, or perhaps the pg_hba.conf needs to be fixed.
Step 1: Verify that the database is running
The command may vary depending on your operating system. But on most *ix systems the following would work, it will search for postgres among all running processes
ps -ef | grep postgres
On my system, mac osx, this spits out
501 408 1 0 2Jul15 ?? 0:21.63 /usr/local/opt/postgresql/bin/postgres -D /usr/local/var/postgres -r /usr/local/var/postgres/server.log
The last column shows the command used to start the server, and the options.
You can look at all the options available to start the postgres server using the following.
man postgres
From there, you'd see that the options -D and -r are respectively the datadir & the logfilename.
Step 2: If the postgres service is running
Use find to search for the location of the socket, which should be somewhere in the /tmp
sudo find /tmp/ -name .s.PGSQL.5432
If postgres is running and accepting socket connections, the above should tell you the location of the socket. On my machine, it turned out to be:
/tmp/.s.PGSQL.5432
Then, try connecting via psql using this file's location explicitly, eg.
psql -h /tmp/ dbname
Step 3: If the service is running but you don't see a socket
If you can't find the socket, but see that the service is running, Verify that the pg_hba.conf file allows local sockets.
Browse to the datadir and you should find the pg_hba.conf file.
By default, near the bottom of the file you should see the following lines:
# "local" is for Unix domain socket connections only
local all all trust
If you don't see it, you can modify the file, and restart the postgres service.
If there is no error in starting the Postgres service, follow these steps
Step 1: Running pg_lsclusters will list all the Postgres clusters running on your device
eg:
Ver Cluster Port Status Owner Data directory Log file
9.6 main 5432 online postgres /var/lib/postgresql/9.6/main /var/log/postgresql/postgresql-9.6-main.log
most probably the status will be down in your case. If not restart PostgreSQL service
Step 2: Restart the pg_ctlcluster
#format is pg_ctlcluster <version> <cluster> <action>
sudo pg_ctlcluster 9.6 main start
#restart PostgreSQL service
sudo service postgresql restart
Step 3: Step 2 failed and threw an error
If restarting pg_lsclusters was not successful, it will throw an error.
My error was(You can see the errors in the logs /var/log/postgresql/postgresql-9.6-main.log)
FATAL: could not access private key file "/etc/ssl/private/ssl-cert-snakeoil.key": Permission denied
Try adding `postgres` user to the group `ssl-cert`
Step 4: check ownership of postgres
Make sure that postgres is the owner of /var/lib/postgresql/version_no/main
eg: sudo chown postgres -R /var/lib/postgresql/9.6/main/
Step 5: Check postgres user belongs to ssl-cert user group
It happened to me and it turned out that I removed erroneously the Postgres user from "ssl-cert" group. Run the below code to fix the user group issue and for fixing the permissions
#set user to group back with
sudo gpasswd -a postgres ssl-cert
# Fixed ownership and mode
sudo chown root:ssl-cert /etc/ssl/private/ssl-cert-snakeoil.key
sudo chmod 740 /etc/ssl/private/ssl-cert-snakeoil.key
# now postgresql starts! (and install command doesn't fail anymore)
sudo service postgresql restart
I experienced this issue when working with PostgreSQL on Ubuntu 18.04.
I checked my PostgreSQL status and realized that it was running fine using:
sudo systemctl status postgresql
I also tried restarting the PotgreSQL server on the machine using:
sudo systemctl restart postgresql
but the issue persisted:
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"?
Following Noushad' answer I did the following:
List all the Postgres clusters running on your device:
pg_lsclusters
this gave me this output in red colour, showing that they were all down and the status also showed down:
Ver Cluster Port Status Owner Data directory Log file
10 main 5432 down postgres /var/lib/postgresql/10/main /var/log/postgresql/postgresql-10-main.log
11 main 5433 down postgres /var/lib/postgresql/11/main /var/log/postgresql/postgresql-11-main.log
12 main 5434 down postgres /var/lib/postgresql/12/main /var/log/postgresql/postgresql-12-main.log
Restart the pg_ctlcluster for one of the server clusters. For me I restarted PG 10:
sudo pg_ctlcluster 10 main start
It however threw the error below, and the same error occurred when I tried restarting other PG clusters:
Job for postgresql#10-main.service failed because the service did not take the steps required by its unit configuration.
See "systemctl status postgresql#10-main.service" and "journalctl -xe" for details.
Check the log for errors, in this case mine is PG 10:
sudo nano /var/log/postgresql/postgresql-10-main.log
I saw the following error:
2020-09-29 02:27:06.445 WAT [25041] FATAL: data directory "/var/lib/postgresql/10/main" has group or world access
2020-09-29 02:27:06.445 WAT [25041] DETAIL: Permissions should be u=rwx (0700).
pg_ctl: could not start server
Examine the log output.
This was caused because I made changes to the file permissions for the PostgreSQL data directory.
I fixed it by running the command below. I ran the command for the 3 PG clusters on my machine:
sudo chmod -R 0700 /var/lib/postgresql/10/main
sudo chmod -R 0700 /var/lib/postgresql/11/main
sudo chmod -R 0700 /var/lib/postgresql/12/main
Afterwhich I restarted each of the PG clusters:
sudo pg_ctlcluster 10 main start
sudo pg_ctlcluster 11 main start
sudo pg_ctlcluster 12 main start
And then finally I checked the health of clusters again:
pg_lsclusters
this time around everything was fine again as the status showed online:
Ver Cluster Port Status Owner Data directory Log file
10 main 5432 online postgres /var/lib/postgresql/10/main /var/log/postgresql/postgresql-10-main.log
11 main 5433 online postgres /var/lib/postgresql/11/main /var/log/postgresql/postgresql-11-main.log
12 main 5434 online postgres /var/lib/postgresql/12/main /var/log/postgresql/postgresql-12-main.log
That's all.
I hope this helps
In my case the following worked for starting postgres after running into the error
sudo service postgresql start
sudo su - postgres
psql
I have encountered a similar issue a couple of times. Normally I just do a fresh installation of PostgreSQL following this tutorial and that solves the problem at the expense of losing data.
I was determined on getting real fix today. Restarting PostgreSQL resolved it on ubuntu. sudo /etc/init.d/postgresql restart
If you are using WSL 2 use this :
sudo service postgresql start
I was facing same problem and
sudo su - postgres
initdb --locale en_US.UTF-8 -D /var/lib/postgres/data
exit
sudo systemctl start postgresql
sudo systemctl status postgresql
This worked for me.
Solved it! Although I don't know what happened, but I just deleted all the stuff and reinstalled it. This is the command I used to delete it sudo apt-get --purge remove postgresql\* and dpkg -l | grep postgres. The latter one is to find all the packets in case it is not clean.
quick howto on debian to remotely access postgres database on server from the psql client: (the changed config is doc'd in the files):
edit /etc/postgresql/10/main/postgresql.conf with listen_address *
edit /etc/postgresql/10/main/pg_hba.conf and add line in the end with host all all 0/0 md5
create login role postgres=# CREATE ROLE remoteuser LOGIN WITH PASSWORD 'foo'
sudo /etc/init.d/postgresql restart changes take effect
login from clientside with psql --host=ipofserver --port=5432 --username=remoteuser --password --dbname=mydb
the password is interactivly asked which in this case is foo
I resolved this problem by checking my file system
the disk was completely full, and so database could not start up
connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432" ?
I tried series of troubleshooting, until when i checked my disk usage and found that it was full, 100% usage,
df -h
cd /var/log/odoo/
cat /dev/null > odoo-server.log
reboot
The error means that the Postgres server is not running. Try starting it:
sudo systemctl start postgresql
Make sure that the server starts on boot:
sudo systemctl enable postgresql
if you are using windows subsystem for linux and Ruby on Rails then check your postgres is running in which port using this command
sudo nano /etc/postgresql/12/main/postgresql.conf if it is in port 5433 then go to database.yml file and add port:5433 in there
and then run command sudo service postgresql start
i have resolved my issue like this
I had the same issue on Devuan ascii (maybe Debian, too?). The config file /etc/postgresql/9.6/main/postgresql.conf contains a directive unix_socket_directories which points to /var/run/postgresql by default. Changing it to /tmp, where most clients look by default, fixed it for me.
I believe I fell into this issue after uninstalling PostgreSQL 11 and 12 while already installed 13 on on Ubuntu 21. I just solved this issue by sudo nano /etc/postgresql/13/main/postgresql.conf, and found that port = 5433 (don't know why). So I changed port = 5432. Then problem solved.
In Ubuntu 20.04.4 LTS.
I was worried about the socket connection because i was using:
psql -U postgres db_omm < db.pgsql
and the error was:
Error: connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: FATAL: Peer authentication failed for user "postgres"
But the authentication uses the user permissions. So even if you specify the user and you are in root or other one, you have to switch to postgres
su - postgres
Then it worked!
My issue with this error message was in wrong permissions on key and pem certificates, which I have manipulated. What helped me a lot was:
/var/log/postgresql/postgresql-9.5-main.log where are all the errors.
I had the same problem.
It seems that there is no socket when there is no cluster.
The default cluster creation failed during the installation because no default locale was set.
In my case I had this error, /var/run/postgresql/.s.PGSQL.5433 (note, one number up from the file it was looking for, .s.PGSQL.5432) was present. Tried the instructions at the top of this page but nothing worked.
Turns out there was an old directory for PostGreSQL 12 config files in /etc/postgresql/12, which I deleted, which solved the issue.
Just want to make a small addition: if your instance is complaining on a socket, you can also check unix_socket_directories at /data/postgresql.conf file which could have been set to /tmp, for example, if you have used a 3rd party distribution. You can change it to /var/run/postgresql and restart the service. That may also require creating a postgresql dir at /var/run and subsys/postgresql-9.6 at /var/lock if those doesn't already exist (worked for me with postgresql 9.6).
During fresh installation of postgresql. By default, user name and password is assigned as "postgres". The feature this RDBMS provides is to add role for new user and create database. If you are getting such errors:
login in by default username:
root#kalilinux:~# sudo -i -u postgres
ype psql for interactive prompt
postgres#kalilinux:~$ psql
To quit from prompt use
\q
To create new user role
postgres#kalilinux:~$ createuser --interactive
Now you are in interacive psql shell. Enjoy. Dont forget to login in from your username and type psql for shell.
It can cause anything for example, my issue was caused for typo error on configuration files.
Some of people says caused by certificate files, another group says caused by unmatched locals.
If you cant find any solution about your issue, remove postgres and reinstall it.This is the best solution.
I had the similar issue and the problem was in the config file pg_hba.conf. I had earlier made some changes which was causing the server to error out while trying to start it. Commenting out the extra additions solved the problem.
Restarting the instance worked for me. Also, as mentioned in some other post psql -h '/tmp' worked as well before the restart. But post restart psql directly started working.
So, probably some file ownership issues that got reset with the restart is what I am thinking.
Verify that Postgres is running using:
ps -ef | grep postgres
root#959dca34cc6d:/var/lib/edb# ps -ef|grep postgres
enterpr+ 476 1 0 06:38 ? 00:00:00 /usr/lib/edb-as/11/bin/edb-postgres -D /var/lib/edb-as/11/main2 -c config_file=/etc/edb-as/11/main2/postgresql.conf
Check for data directory and postgresql.conf.
In my case data directory in -D was different than that in postgresql.conf
So I changed the data directory in postgresql.conf and it worked.
I could resolve this by setting the right permissions to datadir.
It should be
chmod 700 /var/lib/postgresql/10/main
chown postgres.postgres /var/lib/postgresql/10/main
In my case, the service was running but the cluster was down and psql wouldn't start. My configuration files looked perfect but it kept throwing configuration errors and seemed to ignore the changes I was making.
It turns out that whenever you use ALTER SYSTEM SET ... syntax, PostgreSQL writes to a file called postgresql.auto.conf. That file is read in addition to the regular postgresql.conf and pg_hba.conf files. In my distribution of Ubuntu (18.04), they are in different folders(!):
- pg_hba.conf and postgresql.conf are both in /etc/postgresql/12/main
- The auto-generated file is /var/lib/postgresql/12/main/postgresql.auto.conf
I had tried to change the configuration using ALTER SYSTEM SET listen_addresses = <my-ip>, but had made a mistake and that created a broken "ghost" configuration that I couldn't find. As soon as I erased the offending line in postgresql.auto.conf, it fixed everything.
If your service is not secure, this may be the reason
vi /etc/postgresql/11/main/pg_hba.conf
open hba config file, this config file usualy located in the etc directory.
host all all localhost trust md5
you can remove the trust keyword
save pg_hba.conf
sudo service postgresql restart.
In my case I saw this error and postgres was not running.
The problem was that the instalation failed to create the required cluster.
The solution was to create the folder /etc/postgres/{postgresql-version}/main
and then create the cluster with:
pg_createcluster {postgresql-version} main
After that wiht just restarting the postgresql service everything should work.
OK in my case, I uninstalled postgres 10 , but not successfully ,some pg10 file/process still remains there.
and then I installed postgres 13, so pg 13 think there is another pg running on port 5432, so it's using 5433.
solution: purge all your pg via: sudo apt-get --purge remove postgresql postgresql-*
and then re-install it. ( caution: this will remove all your existing data )
on rebooting the server i found these in 2 locations
srwxrwxrwx 1 postgres postgres 0 Nov 10 18:44 .s.PGSQL.5432
-rw------- 1 postgres postgres 48 Nov 10 18:44 .s.PGSQL.5432.lock
both these files were present in below locations and were not present before reboot
/var/run/postgresql/
/tmp/
make sure these files with the corresponding permissions are available and start the psql
I'm trying to create simple postgres server with docker. I use the official postgres image as a base for my container.
My Dockerfile contains these commands:
FROM postgres
USER postgres
RUN /etc/init.d/postgresql start &&\
psql --command "CREATE USER user WITH SUPERUSER PASSWORD 'user';" &&\
createdb -O user app
And when I try to run it I have an 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"?
What I'm doing wrong?
It's possible that it takes some time for postgres to start accepting connections. The way you've written it, it will call CREATE USER immediately after the start function returns. Try putting a sleep in there and see if it's still a problem.
Use pg_ctl with the -w flag so the command will finish when the server has started. No more wondering about whether we have waited long enough. And we can actually stop the server the same way
sudo -u postgres pg_ctl start -w -D ${PGDATA}
sudo -u postgres psql --command "CREATE USER user WITH SUPERUSER PASSWORD 'user';" &&\
sudo -u postgres createdb -O user app
sudo -u postgres pg_ctl stop -w
Had the same problem inside a script in entry point. Following is my Dockerfile excerpt
# init execution
ENTRYPOINT ["/usr/local/sbin/initpostgres.sh"]
with following commands inside the intipostgres.sh script
su postgres -c "pg_ctl start -l /var/lib/postgresql/logpostgres"
su postgres -c "createuser -s $OPENERPUSER"
adding sleep 1 before the createuser command per #seanmcl suggested correction worked for me :
su postgres -c "pg_ctl start -l /var/lib/postgresql/logpostgres"
sleep 1
su postgres -c "createuser -s $OPENERPUSER"
The problem seems to be that the postgres unix socket is not on your host machine. You can fix this by running the following command.
docker run -p 5432:5432 --volume="/run/postgresql:/run/postgresql" -d --name postgres postgres
The essential part is the --volume flag. It links the folder that includes the unix socket file .s.PGSQL.5432 to the host machine in order to be read by other processes.
This seems like a duplicate question of Installing PostgreSQL within a docker container, is that right OP?