Psql error connection to server on socket var run postgresql s pgsql 5432 - Исправление ошибок и поиск оптимальных решений проблем

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

Источник

This issue comes from installing the postgres package without 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, which will remove everything of the old installation, including databases, so back up your databases first.. 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.

Thomas Ward♦

70.4k29 gold badges173 silver badges236 bronze badges

answered Aug 19, 2013 at 23:54

StewartStewart

1,1581 gold badge7 silver badges7 bronze badges

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.

answered Jun 27, 2011 at 17:41

This 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

Also, 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             192.168.1.0/24          md5

Zanna♦

68.3k55 gold badges210 silver badges320 bronze badges

answered Oct 9, 2014 at 13:17

angelousangelous

3813 silver badges2 bronze badges

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.

answered Jun 26, 2011 at 12:51

Riccardo MurriRiccardo Murri

16.2k7 gold badges52 silver badges51 bronze badges

Just create a softlink like this :

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

answered Jul 9, 2012 at 1:35

UrielUriel

2012 silver badges2 bronze badges

I make it work by doing this:

dpkg-reconfigure locales

Choose your preferred locales then run

pg_createcluster 9.5 main --start

(9.5 is my version of postgresql)

/etc/init.d/postgresql start

and then it works!

sudo su - postgres
psql

Zanna♦

68.3k55 gold badges210 silver badges320 bronze badges

answered Sep 13, 2016 at 9:05

mymusisemymusise

1911 silver badge2 bronze badges

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.

Peachy

6,98710 gold badges36 silver badges45 bronze badges

answered Nov 6, 2012 at 3:22

JoeJoe

611 silver badge1 bronze badge

If your Postgres service is up and running without any error or there is no error in starting the Postgres service and still you are getting the mentioned error, follow these steps

Step1: 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 and postgres 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 error

If this process is not successful it will throw an error. You can see the error log on /var/log/postgresql/postgresql-9.6-main.log

My error was:

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

If not, run

sudo chown postgres -R /var/lib/postgresql/9.6/main/

Step 5: Check postgres user belongs to ssl-cert user group

It turned out that I had erroneously removed the Postgres user from the ssl-cert group. Run the below code to fix the user group issue and fix the permissions

#set user to group back with
sudo gpasswd -a postgres ssl-cert

# Fix 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

answered Apr 16, 2018 at 14:44

NoushadNoushad

1711 silver badge5 bronze badges

I found uninstalling Postgres sounds unconvincing.
This helps to solve my problem:

Start the postgres server:
```
sudo systemctl start postgresql
```
Make sure that the server starts on boot:
```
sudo systemctl enable postgresql
```

Detail information can be found on DigitalOcean site Here.

answered Feb 1, 2018 at 15:45

parladparlad

2294 silver badges11 bronze badges

Solution:

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

answered Feb 23, 2016 at 21:47

In my case it was caused by a typo I made while editing /etc/postgresql/9.5/main/pg_hba.conf

I changed:

# Database administrative login by Unix domain socket
local   all             postgres                                peer

to:

# Database administrative login by Unix domain socket
local   all             postgres                                MD5

But MD5 had to be lowercase md5:

# Database administrative login by Unix domain socket
local   all             postgres                                md5

answered Nov 29, 2016 at 10:15

I failed to solve this problem with my postgres-9.5 server. After 3 days of zero progress trying every permutation of fix on this and other sites I decided to re-install the server and lose 5 days worth of work. But, I did replicate the issue on the new instance. This might provide some perspective on how to fix it before you take the catastrophic approach I did.

First, disable all logging settings in postgresql.conf. This is the section:

# ERROR REPORTING AND LOGGING

Comment out everything in that section. Then restart the service.

When restarting, use /etc/init.d/postgresql start or restart
I found it helpful to be in superuser mode while restarting. I had a x-window open just for that operation. You can establish that superuser mode with sudo -i.

Verify that the server can be reached with this simple command: psql -l -U postgres

If that doesn’t fix it, then consider this:

I was changing the ownership on many folders while trying to find a solution. I knew that I’d probably be trying to revert those folder ownerships and chmods for 2 more days. If you have already messed with those folder ownerships and don’t want to completely purge your server, then start tracking the settings for all impacted folders to bring them back to the original state. You might want to try to do a parallel install on another system and systematically check the ownership and settings of all folders. Tedious, but you may be able to get access to your data.

Once you do gain access, systematically change each relevant line in the # ERROR REPORTING AND LOGGING section of the postgresql.conf file. Restart and test. I found that the default folder for the logs was causing a failure. I specifically commented out log_directory. The default folder the system drops the logs into is then /var/log/postgresql.

Zanna♦

68.3k55 gold badges210 silver badges320 bronze badges

answered Jan 19, 2017 at 1:34

Possibly it could have happened because you changed the permissions of the /var/lib/postgresql/9.3/main folder.

Try changing it to 700 using the command below:

sudo chmod 700 main

Zanna♦

68.3k55 gold badges210 silver badges320 bronze badges

answered Nov 6, 2014 at 13:01

This is not exactly related to the question since I’m using Flask, but this was the exact error I was getting and this was the most relevant thread to get ideas.

My setup: Windows Subsystem for Linux, Docker-compose w/ makefile w/ dockerfile, Flask, Postgresql (using a schema consisting of tables)

To connect to postgres, setup your connection string like this:

from flask import Flask
app = Flask(__name__)
app.config['SQLALCHEMY_DATABASE_URI'] = "postgresql+psycopg2://<user>:<password>@<container_name_in_docker-compose.yml>/<database_name>"

NOTE: I never got any IP (e.g. localhost, 127.0.0.1) to work using any method in this thread. Idea for using the container name instead of localhost came from here: https://github.com/docker-library/postgres/issues/297

Set your schema:

from sqlalchemy import MetaData
db = SQLAlchemy(app, metadata=MetaData(schema="<schema_name>"))

Set your search path for your functions when you setup your session:

db.session.execute("SET search_path TO <schema_name>")

answered Mar 29, 2019 at 21:30

The most upvoted answer isn’t even remotely correct because you can see in the question the server is running on the expected port (he shows this with netstat).

While the OP did not mark the other answer as chosen, they commented that the other answer (which makes sense and works) was sufficient,

But for these reasons that solution is poor and insecure even if it the server wasn’t running on port 5432:

What you’re doing here when you say --purge is you’re deleting the configuration file for PostgreSQL ((as well as all of the data with the database. You or may not even see a warning about this, but here is the warning just to show you now,

Removing the PostgreSQL server package will leave existing database clusters intact, i.e. their configuration, data, and log directories will not be removed. On purging the package, the directories can optionally be removed. Remove PostgreSQL directories when package is purged? [prompt for yes or no]

When you add it again PostgreSQL is reinstalling it to a port number that’s not taken (which may be the port number you expect). Before you even try this solution, you need to answer a few questions along the same line:

Do I want multiple versions of PostgreSQL on my machine?
Do I want an older version of PostgreSQL?
What do I want to happen when I dist-upgrade and there is a newer version?

Currently when you dist-upgrade on Ubuntu (and any Debian variant), the new version of PostgreSQL is installed alongside the old copy and the port number on the new copy is the port number of the old copy + 1. So you can just start it up, increment the port number in your client and you’ve got a new install! And you have the old install to fall back on — it’s safe!

However, if you only one want version of PostgreSQL purging to change the configuration is still not the right option because it will destroy your database. The only time this could even be acceptable is you want to destroy everything related to PostgreSQL. You’re better off ensuring your database is correct and then merely editing the configuration file so the new install runs on the old port number

#!/bin/bash

# We can find the version number of the newest PostgreSQL with this
VERSION=$(dpkg-query -W -f "${Version}" 'postgresql' | sed -e's/+.*//')
PGCONF="/etc/postgresql/${VERSION}/main/postgresql.conf"

# Then we can update the port.
sudo sed -ie '/port = /s/.*/port = 5432/' "$PGCONF"

sudo systemctl restart postgresql

Do not install a specific version of PostgreSQL. Only ever install postgresql. If you install a specific version then when you dist-upgrade your version will simply remain on your computer forever without upgrades. The repo will no longer have the security patches for the old version (which they don’t support). This must always be suboptimal to getting a newer version that they do support, running on a different port number.

answered Aug 4, 2021 at 18:30

Evan CarrollEvan Carroll

7,49915 gold badges53 silver badges86 bronze badges

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.

answered Nov 20, 2015 at 16:44

In my case, all i had to do was this:

sudo service postgresql restart

and then

sudo -u postgres psql

This worked just fine.
Hope it helps.
Cheers .

answered Jun 29, 2017 at 17:21

Find your file:

sudo find /tmp/ -name .s.PGSQL.5432

Result:

/tmp/.s.PGSQL.5432

su postgres
psql -h /tmp/ yourdatabase

Zanna♦

68.3k55 gold badges210 silver badges320 bronze badges

answered Jan 30, 2017 at 15:18

I had the same problem (on Ubuntu 15.10 (wily)). 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 similar 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 - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add -

If not using wily, replace wily with your release, i.e with the output of lsb_release -cs

sudo sh -c 'echo "deb http://apt.postgresql.org/pub/repos/apt/ wily-pgdg main" >> /etc/apt/sources.list.d/postgresql.list'
sudo apt-get update && sudo apt-get install postgresql-9.3 pgadmin3

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

Expected output:

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)

Zanna♦

68.3k55 gold badges210 silver badges320 bronze badges

answered Feb 5, 2016 at 16:43

While having the same issue I tried something different:

Starting the postgresql daemon manually 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 the problem!

Here’s the full 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.

Zanna♦

68.3k55 gold badges210 silver badges320 bronze badges

answered Jun 26, 2013 at 13:29

After many exhausting attempts, I found the solution based on other posts!

dpkg -l | grep postgres
apt-get --purge remove <package-founded-1> <package-founded-2>
whereis postgres
whereis postgresql
sudo rm -rf <paths-founded>
sudo userdel -f postgres

Kevin Bowen

19.2k55 gold badges75 silver badges81 bronze badges

answered Apr 22, 2019 at 23:46

Check the status of postgresql:
```
service postgresql status
```
If it shows online, proceed to step no 3 else execute step no 2.
To make postgresql online, execute the following command:
```
sudo service postgresql start
```
Now check the status by running the command of the previous step. It should show online.
To start psql session, execute the following command:
```
sudo su postreg
```
Finally, check if it’s working or not by executing:
```
psql
```

answered May 29, 2021 at 12:21

Restart postgresql by using the command

sudo /opt/bitnami/ctlscript.sh restart postgresql

answered Apr 26, 2022 at 9:41

This error could mean a lot of different things.

In my case, I was running PostgreSQL 12 on a virtual machine.

I had changed the shared_buffer config and apparently, the system administrator edited the memory config for the virtual machine reducing the RAM allocation from where it was to below what I had set for the shared_buffer.

I figured that out by looking at the log in

/var/log/postgresql/postgresql-12-main.log

and after that I restarted the service using

sudo systemctl restart postgresql.service

that’s how it worked

answered Jun 30, 2022 at 9:47

Create postgresql directory inside run and then run the following command.

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

answered Apr 26, 2019 at 5:35

Simply add /tmp unix_socket_directories

postgresql.conf

unix_socket_directories = '/var/run/postgresql,/tmp'

answered Jun 17, 2019 at 1:00

I had this problem with another port. The problem was, that I had a system variable in /etc/environments with the following value:

PGPORT=54420

As I removed it (and restarted), psql was able to connect.

answered Jul 18, 2021 at 14:46

BevorBevor

4908 silver badges17 bronze badges

Источник

I know this is an old track, but I got the same exact issue and I solved it using some of the information I found here. so I would like to share this with you.
I’m using Kali linux (Linux kali 6.0.0-kali6-amd64) 2022-12-19 running on VMWare VM.
When I run Metasploit database manager I get this:

    └─$ sudo msfdb reinit

[i] Database already started psql: error: connection to server on
socket «/var/run/postgresql/.s.PGSQL.5432» failed: No such file or
directory
Is the server running locally and accepting connections on that socket? psql: error: connection to server on socket
«/var/run/postgresql/.s.PGSQL.5432» failed: No such file or directory
Is the server running locally and accepting connections on that socket? psql: error: connection to server on socket
«/var/run/postgresql/.s.PGSQL.5432» failed: No such file or directory
Is the server running locally and accepting connections on that socket? [+] Deleting configuration file
/usr/share/metasploit-framework/config/database.yml [+] Stopping
database [+] Starting database psql: error: connection to server on
socket «/var/run/postgresql/.s.PGSQL.5432» failed: No such file or
directory
Is the server running locally and accepting connections on that socket? [+] Creating database user ‘msf’ createuser: error:
connection to server on socket «/var/run/postgresql/.s.PGSQL.5432»
failed: No such file or directory
Is the server running locally and accepting connections on that socket? psql: error: connection to server on socket
«/var/run/postgresql/.s.PGSQL.5432» failed: No such file or directory
Is the server running locally and accepting connections on that socket? [+] Creating databases ‘msf’ createdb: error: connection
to server on socket «/var/run/postgresql/.s.PGSQL.5432» failed: No
such file or directory
Is the server running locally and accepting connections on that socket? psql: error: connection to server on socket
«/var/run/postgresql/.s.PGSQL.5432» failed: No such file or directory
Is the server running locally and accepting connections on that socket? [+] Creating databases ‘msf_test’ createdb: error:
connection to server on socket «/var/run/postgresql/.s.PGSQL.5432»
failed: No such file or directory
Is the server running locally and accepting connections on that socket? [+] Creating configuration file
‘/usr/share/metasploit-framework/config/database.yml’ [+] Creating
initial database schema rake aborted!
ActiveRecord::ConnectionNotEstablished: connection to server at «::1»,
port 5432 failed: Connection refused
Is the server running on that host and accepting TCP/IP connections? connection to server at «127.0.0.1», port 5432 failed:
Connection refused
Is the server running on that host and accepting TCP/IP connections?
/usr/share/metasploit-framework/vendor/bundle/ruby/3.0.0/gems/activerecord-6.1.7/lib/active_record/connection_adapters/postgresql_adapter.rb:83:in
rescue in new_client' /usr/share/metasploit-framework/vendor/bundle/ruby/3.0.0/gems/activerecord-6.1.7/lib/active_record/connection_adapters/postgresql_adapter.rb:77:in new_client’
/usr/share/metasploit-framework/vendor/bundle/ruby/3.0.0/gems/activerecord-6.1.7/lib/active_record/connection_adapters/postgresql_adapter.rb:37:in
postgresql_connection' /usr/share/metasploit-framework/vendor/bundle/ruby/3.0.0/gems/activerecord-6.1.7/lib/active_record/connection_adapters/abstract/connection_pool.rb:882:in public_send’
/usr/share/metasploit-framework/vendor/bundle/ruby/3.0.0/gems/activerecord-6.1.7/lib/active_record/connection_adapters/abstract/connection_pool.rb:882:in
new_connection' /usr/share/metasploit-framework/vendor/bundle/ruby/3.0.0/gems/activerecord-6.1.7/lib/active_record/connection_adapters/abstract/connection_pool.rb:926:in checkout_new_connection’
/usr/share/metasploit-framework/vendor/bundle/ruby/3.0.0/gems/activerecord-6.1.7/lib/active_record/connection_adapters/abstract/connection_pool.rb:905:in
try_to_checkout_new_connection' /usr/share/metasploit-framework/vendor/bundle/ruby/3.0.0/gems/activerecord-6.1.7/lib/active_record/connection_adapters/abstract/connection_pool.rb:866:in acquire_connection’
/usr/share/metasploit-framework/vendor/bundle/ruby/3.0.0/gems/activerecord-6.1.7/lib/active_record/connection_adapters/abstract/connection_pool.rb:588:in
checkout' /usr/share/metasploit-framework/vendor/bundle/ruby/3.0.0/gems/activerecord-6.1.7/lib/active_record/connection_adapters/abstract/connection_pool.rb:428:in connection’
/usr/share/metasploit-framework/vendor/bundle/ruby/3.0.0/gems/activerecord-6.1.7/lib/active_record/connection_adapters/abstract/connection_pool.rb:1128:in
retrieve_connection' /usr/share/metasploit-framework/vendor/bundle/ruby/3.0.0/gems/activerecord-6.1.7/lib/active_record/connection_handling.rb:327:in retrieve_connection’
/usr/share/metasploit-framework/vendor/bundle/ruby/3.0.0/gems/activerecord-6.1.7/lib/active_record/connection_handling.rb:283:in
connection' /usr/share/metasploit-framework/vendor/bundle/ruby/3.0.0/gems/activerecord-6.1.7/lib/active_record/tasks/database_tasks.rb:237:in migrate’
/usr/share/metasploit-framework/vendor/bundle/ruby/3.0.0/gems/activerecord-6.1.7/lib/active_record/railties/databases.rake:92:in
block (3 levels) in <top (required)>' /usr/share/metasploit-framework/vendor/bundle/ruby/3.0.0/gems/activerecord-6.1.7/lib/active_record/railties/databases.rake:90:in each’
/usr/share/metasploit-framework/vendor/bundle/ruby/3.0.0/gems/activerecord-6.1.7/lib/active_record/railties/databases.rake:90:in
block (2 levels) in <top (required)>' /usr/share/metasploit-framework/vendor/bundle/ruby/3.0.0/gems/rake-13.0.6/exe/rake:27:in <top (required)>’
Caused by: PG::ConnectionBad: connection to server at "::1", port 5432 failed: Connection refused
        Is the server running on that host and accepting TCP/IP connections? connection to server at "127.0.0.1", port 5432 failed:
Connection refused
Is the server running on that host and accepting TCP/IP connections?
/usr/share/metasploit-framework/vendor/bundle/ruby/3.0.0/gems/pg-1.4.5/lib/pg/connection.rb:632:in
async_connect_or_reset' /usr/share/metasploit-framework/vendor/bundle/ruby/3.0.0/gems/pg-1.4.5/lib/pg/connection.rb:760:in connect_to_hosts’
/usr/share/metasploit-framework/vendor/bundle/ruby/3.0.0/gems/pg-1.4.5/lib/pg/connection.rb:695:in
new' /usr/share/metasploit-framework/vendor/bundle/ruby/3.0.0/gems/pg-1.4.5/lib/pg.rb:69:in connect’
/usr/share/metasploit-framework/vendor/bundle/ruby/3.0.0/gems/activerecord-6.1.7/lib/active_record/connection_adapters/postgresql_adapter.rb:78:in
new_client' /usr/share/metasploit-framework/vendor/bundle/ruby/3.0.0/gems/activerecord-6.1.7/lib/active_record/connection_adapters/postgresql_adapter.rb:37:in postgresql_connection’
/usr/share/metasploit-framework/vendor/bundle/ruby/3.0.0/gems/activerecord-6.1.7/lib/active_record/connection_adapters/abstract/connection_pool.rb:882:in
public_send' /usr/share/metasploit-framework/vendor/bundle/ruby/3.0.0/gems/activerecord-6.1.7/lib/active_record/connection_adapters/abstract/connection_pool.rb:882:in new_connection’
/usr/share/metasploit-framework/vendor/bundle/ruby/3.0.0/gems/activerecord-6.1.7/lib/active_record/connection_adapters/abstract/connection_pool.rb:926:in
checkout_new_connection' /usr/share/metasploit-framework/vendor/bundle/ruby/3.0.0/gems/activerecord-6.1.7/lib/active_record/connection_adapters/abstract/connection_pool.rb:905:in try_to_checkout_new_connection’
/usr/share/metasploit-framework/vendor/bundle/ruby/3.0.0/gems/activerecord-6.1.7/lib/active_record/connection_adapters/abstract/connection_pool.rb:866:in
acquire_connection' /usr/share/metasploit-framework/vendor/bundle/ruby/3.0.0/gems/activerecord-6.1.7/lib/active_record/connection_adapters/abstract/connection_pool.rb:588:in checkout’
/usr/share/metasploit-framework/vendor/bundle/ruby/3.0.0/gems/activerecord-6.1.7/lib/active_record/connection_adapters/abstract/connection_pool.rb:428:in
connection' /usr/share/metasploit-framework/vendor/bundle/ruby/3.0.0/gems/activerecord-6.1.7/lib/active_record/connection_adapters/abstract/connection_pool.rb:1128:in retrieve_connection’
/usr/share/metasploit-framework/vendor/bundle/ruby/3.0.0/gems/activerecord-6.1.7/lib/active_record/connection_handling.rb:327:in
retrieve_connection' /usr/share/metasploit-framework/vendor/bundle/ruby/3.0.0/gems/activerecord-6.1.7/lib/active_record/connection_handling.rb:283:in connection’
/usr/share/metasploit-framework/vendor/bundle/ruby/3.0.0/gems/activerecord-6.1.7/lib/active_record/tasks/database_tasks.rb:237:in
migrate' /usr/share/metasploit-framework/vendor/bundle/ruby/3.0.0/gems/activerecord-6.1.7/lib/active_record/railties/databases.rake:92:in block (3 levels) in <top (required)>’
/usr/share/metasploit-framework/vendor/bundle/ruby/3.0.0/gems/activerecord-6.1.7/lib/active_record/railties/databases.rake:90:in
each' /usr/share/metasploit-framework/vendor/bundle/ruby/3.0.0/gems/activerecord-6.1.7/lib/active_record/railties/databases.rake:90:in block (2 levels) in <top (required)>’
/usr/share/metasploit-framework/vendor/bundle/ruby/3.0.0/gems/rake-13.0.6/exe/rake:27:in
`<top (required)>’ Tasks: TOP => db:migrate (See full trace by running
task with —trace)

I searched every where and used every thing I could find, but nothing work. However, folowing some hints from this track. I was able to solve the issue.

When I typed :

$ pg_lsclusters

I got :

Ver Cluster Port Status Owner Data directory
Log file 14 main 5432 down, postgres
/var/lib/postgresql/14/main /var/log/postgresql/postgresql-14-main.log
15 main 5433 online postgres
/var/lib/postgresql/15/main /var/log/postgresql/postgresql-15-main.log

This means that the older version «14» which uses the port «5432» required by «msfbd» is down whilst version «15» which is «online» uses «5433».
so simply changes the port using :

sudo PGPORT=5433 msfdb init

And voilà, it’s working just fine.

$ msfconsole

Call trans opt: received. 2-19-98 13:24:18 REC:Loc

 Trace program: running                                                                                                                                                                                                                 
                                                                                                                                                                                                                                        
       wake up, Neo...                                                                                                                                                                                                                  
    the matrix has you                                                                                                                                                                                                                  
  follow the white rabbit.

      knock, knock, Neo.

                    (`.         ,-,
                    ` `.    ,;' /
                     `.  ,'/ .'
                      `. X /.'
            .-;--''--.._` ` (
          .'            /   `
         ,           ` '   Q '
         ,         ,   `._    
      ,.|         '     `-.;_'
      :  . `  ;    `  ` --,.._;
       ' `    ,   )   .'
          `._ ,  '   /_
             ; ,''-,;' ``-
              ``-..__``--`

                         https://metasploit.com

   =[ metasploit v6.2.31-dev                          ]

— —=[ 2274 exploits — 1192 auxiliary — 405 post ]
— —=[ 951 payloads — 45 encoders — 11 nops ]
— —=[ 9 evasion ]

Metasploit tip: Tired of setting RHOSTS for modules? Try globally
setting it with setg RHOSTS x.x.x.x Metasploit Documentation:
https://docs.metasploit.com/

msf6 >

I guess that the problem occurred after a system update.

Источник

Before anyone can access the database, you must start the database server. The database server program is called postgres.

If you are using a pre-packaged version of PostgreSQL, it almost certainly includes provisions for running the server as a background task according to the conventions of your operating system. Using the package’s infrastructure to start the server will be much less work than figuring out how to do this yourself. Consult the package-level documentation for details.

The bare-bones way to start the server manually is just to invoke postgres directly, specifying the location of the data directory with the -D option, for example:

$ postgres -D /usr/local/pgsql/data

which will leave the server running in the foreground. This must be done while logged into the PostgreSQL user account. Without -D, the server will try to use the data directory named by the environment variable PGDATA. If that variable is not provided either, it will fail.

Normally it is better to start postgres in the background. For this, use the usual Unix shell syntax:

$ postgres -D /usr/local/pgsql/data >logfile 2>&1 &

It is important to store the server’s stdout and stderr output somewhere, as shown above. It will help for auditing purposes and to diagnose problems. (See Section 25.3 for a more thorough discussion of log file handling.)

The postgres program also takes a number of other command-line options. For more information, see the postgres reference page and Chapter 20 below.

This shell syntax can get tedious quickly. Therefore the wrapper program pg_ctl is provided to simplify some tasks. For example:

pg_ctl start -l logfile

will start the server in the background and put the output into the named log file. The -D option has the same meaning here as for postgres. pg_ctl is also capable of stopping the server.

Normally, you will want to start the database server when the computer boots. Autostart scripts are operating-system-specific. There are a few example scripts distributed with PostgreSQL in the contrib/start-scripts directory. Installing one will require root privileges.

Different systems have different conventions for starting up daemons at boot time. Many systems have a file /etc/rc.local or /etc/rc.d/rc.local. Others use init.d or rc.d directories. Whatever you do, the server must be run by the PostgreSQL user account and not by root or any other user. Therefore you probably should form your commands using su postgres -c '...'. For example:

su postgres -c 'pg_ctl start -D /usr/local/pgsql/data -l serverlog'

Here are a few more operating-system-specific suggestions. (In each case be sure to use the proper installation directory and user name where we show generic values.)

For FreeBSD, look at the file contrib/start-scripts/freebsd in the PostgreSQL source distribution.

On OpenBSD, add the following lines to the file /etc/rc.local:

if [ -x /usr/local/pgsql/bin/pg_ctl -a -x /usr/local/pgsql/bin/postgres ]; then
    su -l postgres -c '/usr/local/pgsql/bin/pg_ctl start -s -l /var/postgresql/log -D /usr/local/pgsql/data'
    echo -n ' postgresql'
fi

On Linux systems either add
```
/usr/local/pgsql/bin/pg_ctl start -l logfile -D /usr/local/pgsql/data
```
to /etc/rc.d/rc.local or /etc/rc.local or look at the file contrib/start-scripts/linux in the PostgreSQL source distribution.

When using systemd, you can use the following service unit file (e.g., at /etc/systemd/system/postgresql.service):
```
[Unit]
Description=PostgreSQL database server
Documentation=man:postgres(1)
After=network-online.target
Wants=network-online.target

[Service]
Type=notify
User=postgres
ExecStart=/usr/local/pgsql/bin/postgres -D /usr/local/pgsql/data
ExecReload=/bin/kill -HUP $MAINPID
KillMode=mixed
KillSignal=SIGINT
TimeoutSec=infinity

[Install]
WantedBy=multi-user.target
```
Using Type=notify requires that the server binary was built with configure --with-systemd.

Consider carefully the timeout setting. systemd has a default timeout of 90 seconds as of this writing and will kill a process that does not report readiness within that time. But a PostgreSQL server that might have to perform crash recovery at startup could take much longer to become ready. The suggested value of infinity disables the timeout logic.
On NetBSD, use either the FreeBSD or Linux start scripts, depending on preference.
On Solaris, create a file called /etc/init.d/postgresql that contains the following line:
```
su - postgres -c "/usr/local/pgsql/bin/pg_ctl start -l logfile -D /usr/local/pgsql/data"
```
Then, create a symbolic link to it in /etc/rc3.d as S99postgresql.

While the server is running, its PID is stored in the file postmaster.pid in the data directory. This is used to prevent multiple server instances from running in the same data directory and can also be used for shutting down the server.

19.3.1. Server Start-up Failures

There are several common reasons the server might fail to start. Check the server’s log file, or start it by hand (without redirecting standard output or standard error) and see what error messages appear. Below we explain some of the most common error messages in more detail.

LOG:  could not bind IPv4 address "127.0.0.1": Address already in use
HINT:  Is another postmaster already running on port 5432? If not, wait a few seconds and retry.
FATAL:  could not create any TCP/IP sockets

This usually means just what it suggests: you tried to start another server on the same port where one is already running. However, if the kernel error message is not Address already in use or some variant of that, there might be a different problem. For example, trying to start a server on a reserved port number might draw something like:

$ postgres -p 666
LOG:  could not bind IPv4 address "127.0.0.1": Permission denied
HINT:  Is another postmaster already running on port 666? If not, wait a few seconds and retry.
FATAL:  could not create any TCP/IP sockets

A message like:

FATAL:  could not create shared memory segment: Invalid argument
DETAIL:  Failed system call was shmget(key=5440001, size=4011376640, 03600).

probably means your kernel’s limit on the size of shared memory is smaller than the work area PostgreSQL is trying to create (4011376640 bytes in this example). This is only likely to happen if you have set shared_memory_type to sysv. In that case, you can try starting the server with a smaller-than-normal number of buffers (shared_buffers), or reconfigure your kernel to increase the allowed shared memory size. You might also see this message when trying to start multiple servers on the same machine, if their total space requested exceeds the kernel limit.

An error like:

FATAL:  could not create semaphores: No space left on device
DETAIL:  Failed system call was semget(5440126, 17, 03600).

does not mean you’ve run out of disk space. It means your kernel’s limit on the number of System V semaphores is smaller than the number PostgreSQL wants to create. As above, you might be able to work around the problem by starting the server with a reduced number of allowed connections (max_connections), but you’ll eventually want to increase the kernel limit.

Details about configuring System V IPC facilities are given in Section 19.4.1.

19.3.2. Client Connection Problems

Although the error conditions possible on the client side are quite varied and application-dependent, a few of them might be directly related to how the server was started. Conditions other than those shown below should be documented with the respective client application.

psql: error: connection to server at "server.joe.com" (123.123.123.123), port 5432 failed: Connection refused
        Is the server running on that host and accepting TCP/IP connections?

This is the generic “I couldn’t find a server to talk to” failure. It looks like the above when TCP/IP communication is attempted. A common mistake is to forget to configure the server to allow TCP/IP connections.

Alternatively, you might get this when attempting Unix-domain socket communication to a local server:

psql: error: connection to server on socket "/tmp/.s.PGSQL.5432" failed: No such file or directory
        Is the server running locally and accepting connections on that socket?

If the server is indeed running, check that the client’s idea of the socket path (here /tmp) agrees with the server’s unix_socket_directories setting.

A connection failure message always shows the server address or socket path name, which is useful in verifying that the client is trying to connect to the right place. If there is in fact no server listening there, the kernel error message will typically be either Connection refused or No such file or directory, as illustrated. (It is important to realize that Connection refused in this context does not mean that the server got your connection request and rejected it. That case will produce a different message, as shown in Section 21.15.) Other error messages such as Connection timed out might indicate more fundamental problems, like lack of network connectivity, or a firewall blocking the connection.

Источник

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             127.0.0.1/32            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 127.0.0.1:5432          0.0.0.0:*               LISTEN      14338/postgres  
tcp6       0      0 ::1:5432                :::*                    LISTEN      14338/postgres  
root@assaf-desktop:/home/assaf#

asked Jun 26, 2011 at 12:28

I use following workaround so both clients should be happy:

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

answered Nov 15, 2011 at 14:25

JaakLJaakL

3112 silver badges6 bronze badges

At a guess you’re using the system version of the psql command, which will look for the postgres unix domain sockets in /var/run/postgresql and the third party postgres you are using has been configured to put them somewhere else.

The easiest solution is probably to use /opt/djangostack-1.3-0/postgresql/bin/psql instead, assuming that there is one, as it will presumably look in the correct place for the unix sockets.

Otherwise, you need to look at the unix_socket_directory setting in postgresql.conf but it’s quite likely that will be commented out and it is using a compiled in default.

answered Jun 26, 2011 at 14:42

TomHTomH

1,2907 silver badges9 bronze badges

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

Possible workarounds:

Use the clients supplied by your third-party package (call /opt/djangostack-1.3-0/postgresql/bin/psql). Possibly deinstall 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.

answered Jun 27, 2011 at 17:39

Peter EisentrautPeter Eisentraut

3,6351 gold badge23 silver badges21 bronze badges

Restart postgresql by using the command

sudo /opt/bitnami/ctlscript.sh restart postgresql

This worked for me

answered Apr 26, 2022 at 9:44

Источник

Step1: Running pg_lsclusters will list all the postgres clusters running on your device

Step 2: Restart the pg_ctlcluster

Step 3: Step 2 failed and threw error

Step 4: check ownership of postgres

Step 5: Check postgres user belongs to ssl-cert user group

19.3.1. Server Start-up Failures

19.3.2. Client Connection Problems

Step1: Running `pg_lsclusters` will list all the postgres clusters running on your device