PostgreSQL: 为什么 psql 不能连接到服务器？

解决了！虽然我不知道发生了什么，但我刚刚删除了所有的东西，并重新安装了它。这是我用来删除它的命令 sudo apt-get --purge remove postgresql\*和 dpkg -l | grep postgres。后者是找到所有的数据包，以防它不干净。

错误说明 psql 实用程序找不到连接到数据库服务器的套接字。要么您没有在后台运行数据库服务，要么套接字位于其他地方，或者可能需要修复 pg_hba.conf。

步骤1: 验证数据库是否正在运行

该命令可能会根据您的操作系统而有所不同。但是在大多数 * ix 系统上，下面的代码可以工作，它将在所有正在运行的进程中搜索 postgres

ps -ef | grep postgres

在我的系统里 Mac OSX 会吐出来

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

最后一列显示用于启动服务器的命令和选项。

您可以使用以下方法查看启动 postgres 服务器的所有可用选项。

man postgres

从这里，您将看到选项 -D和 -r分别是 datadir和 logfilename。

步骤2: 如果 postgres 服务正在运行

使用 find搜索套接字的位置，该位置应该在 /tmp中的某个位置

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

如果 postgres 正在运行并接受套接字连接，上面的代码应该会告诉您套接字的位置。在我的机器上，结果是:

/tmp/.s.PGSQL.5432

然后，尝试通过 psql 显式地使用该文件的位置进行连接，例如。

psql -h /tmp/ dbname

步骤3: 如果服务正在运行，但您没有看到一个套接字

如果找不到套接字，但看到服务正在运行，请验证 pg _ hba。Conf 文件允许本地套接字。

浏览到 datadir，应该会找到 pg_hba.conf文件。

默认情况下，在文件底部附近，您应该看到以下行:

# "local" is for Unix domain socket connections only
local       all       all       trust

如果您没有看到它，您可以修改文件，并重新启动 postgres 服务。

只是想做一个小小的补充: 如果您的实例在套接字上抱怨，您也可以在 /data/postgresql.conf文件中检查 unix_socket_directories，这个文件可以设置为 /tmp，例如，如果您使用了第三方发行版。您可以将其更改为 /var/run/postgresql并重新启动服务。这也可能需要在 /var/run创建一个 postgresql目录，在 /var/lock创建一个 subsys/postgresql-9.6目录，如果这些目录还不存在的话(对我来说，在 postgreql 9.6中就可以实现)。

快速如何在 debian 上从 psql 客户端远程访问服务器上的 postgres 数据库: (更改后的配置文档在文件中) :

1. 用 listen _ address * 编辑 /etc/postgresql/10/main/postgresql.conf
2. 编辑 /etc/postgresql/10/main/pg_hba.conf并在结尾用 host all all 0/0 md5添加一行
3. 创建登录角色 postgres=# CREATE ROLE remoteuser LOGIN WITH PASSWORD 'foo'

4. sudo /etc/init.d/postgresql restart变化生效

5. 使用 psql --host=ipofserver --port=5432 --username=remoteuser --password --dbname=mydb从客户端登录

6. 交互式地询问密码，在这种情况下哪个是 foo

我曾多次遇到过类似的问题。通常我只是在这个 教程之后重新安装 PostgreSQL，这样就解决了以丢失数据为代价的问题。

今天我决定要做一个真正的修复，重启 PostgreSQL 在 ubuntu.sudo /etc/init.d/postgresql restart上解决了这个问题

这个错误消息的问题在于密钥和 pem 证书的权限错误，我已经对它们进行了操作。对我帮助很大的是: /var/log/postgreql/postgreql-9.5-main. log，其中包含所有错误。

因此，对于我和我的朋友们来说，我们必须开发一个 Node.js 应用程序(使用 Postgres 和 Sequelize)

1. brew install postgresql(我们中的一个错过了邮政，我们中的一个没有，但是我们得到了相同的错误 msg 如上所列)

2. brew services start postgresql * * * (利用自制程序开始 postgres)

3. createdb <name of database in config.json file>

4. node_modules/.bin/sequelize db:migrate

5. npm start

新安装过程中。默认情况下，用户名和密码被分配为“ postgres”。这个 RDBMS 提供的特性是为新用户添加角色和创建数据库。如果你遇到这样的错误:

1. 默认用户名登录:

   Root@kalilinux: ~ # sudo-i-u postgres

2. 用于交互式提示符

   Postgres@kalilinux: ~ $psql

3. 从即时使用中退出

   问

4. 创建新的用户角色

   Postgres@kalilinux: ~ $createuser —— Interactive

现在您在交互式 psql shell 中。好好享受吧。不要忘记从用户名登录并键入 psql for shell。

如果在启动 Postgres 服务时没有错误，请遵循以下步骤

步骤1: 运行 pg_lsclusters将列出所有在设备上运行的 Postgres 集群

例如:

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

如果不重新启动 PostgreSQL 服务，那么这个状态很可能就会关闭

步骤2: 重新启动 pg _ ctlcluster

#format is pg_ctlcluster <version> <cluster> <action>
sudo pg_ctlcluster 9.6 main start


#restart PostgreSQL service
sudo service postgresql restart

步骤3: 步骤2失败并抛出一个错误

如果重新启动 pg _ lscluster 不成功，它将抛出一个错误。 我的错误是(您可以在日志 /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`

步骤4: 检查 postgres 的所有权

确保 postgres是 /var/lib/postgresql/version_no/main的所有者 例句: sudo chown postgres -R /var/lib/postgresql/9.6/main/

步骤5: 检查 postgres 用户属于 ssl-cert 用户组

它发生在我身上，结果是我错误地从“ ssl-cert”组删除了 Postgres 用户。运行以下代码以修复用户组问题和修复权限

#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

它可以导致任何事情，例如，我的问题是由于配置文件上的输入错误造成的。 一些人说是由证书文件引起的，另一些人说是由不匹配的当地人引起的。

如果你不能找到任何解决你的问题，删除 postgres 和重新安装。这是最好的解决方案。

该错误意味着 Postgres 服务器未运行。请尝试启动它:

sudo systemctl start postgresql

确保服务器在启动时启动:

sudo systemctl enable postgresql

我对 Devuan ascii 也有同样的问题(也许 Debian 也是?).配置文件 /etc/postgresql/9.6/main/postgresql.conf包含一个指令 unix_socket_directories，默认情况下指向 /var/run/postgresql。把它改为 /tmp，大多数客户默认看它，为我修复了它。

我也面临着同样的问题

sudo su - postgres
initdb --locale en_US.UTF-8 -D /var/lib/postgres/data
exit
sudo systemctl start postgresql
sudo systemctl status postgresql

这招对我很管用。

我通过检查文件系统解决了这个问题 磁盘已经完全满了，因此数据库无法启动

连接 Unix domain socket "/var/run/postgresql/.s.PGSQL.5432" ?

我尝试了一系列的故障排除，直到我检查我的磁盘使用情况，发现它是满的，100% 的使用率,

df -h
cd /var/log/odoo/
cat /dev/null > odoo-server.log
reboot

我也有同样的问题。 当没有集群时，似乎就没有套接字。

由于未设置默认语言环境，因此在安装期间默认群集创建失败。

我遇到过类似的问题，问题出在配置文件 pg _ hba 中。保密。我之前做了一些更改，这些更改导致服务器在尝试启动时出错。注释掉额外的添加解决了这个问题。

重启这个实例对我很有用。另外，正如在其他一些文章中提到的，psql-h’/tmp’在重新启动之前也能正常工作。但重新启动后 psql 直接开始工作。 所以，可能有一些文件所有权问题被重新启动重置是我在想什么。

如果您的服务不安全，这可能是原因

vi /etc/postgresql/11/main/pg_hba.conf

1. 打开 hba 配置文件，这个配置文件通常位于 等等目录中。

host    all   all    localhost trust   md5

2. 你可以删除 信任关键字

3. 保存 pg _ hba. conf

4. Sudo 服务后重启。

验证 Postgres 是否正在运行:

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

检查数据目录和 postgresql.conf。

在我的案例中，-D中的数据目录与 postgresql.conf中的不同

所以我改变了 postgresql.conf中的数据目录，它起作用了。

我可以通过设置 datadir 的正确权限来解决这个问题。 应该是的

chmod 700 /var/lib/postgresql/10/main
chown postgres.postgres /var/lib/postgresql/10/main

在我的例子中，服务正在运行，但是集群关闭了，psql 无法启动。我的配置文件看起来很完美，但它不断抛出配置错误，似乎忽略了我正在做的更改。

事实证明，无论何时使用 ALTER SYSTEM SET ...语法，PostgreSQL 都会写入一个名为 postgresql.auto.conf的文件。该文件是读取 除了的常规 postgresql.conf和 pg_hba.conf文件。在我的 Ubuntu (18.04)发行版中，它们在不同的文件夹中(!):
- pg_hba.conf和 postgresql.conf都在 /etc/postgresql/12/main
自动生成的文件是 /var/lib/postgresql/12/main/postgresql.auto.conf

我曾试图使用 ALTER SYSTEM SET listen_addresses = <my-ip>改变配置，但是犯了一个错误，导致我找不到一个坏掉的“幽灵”配置。只要我删除了 postgresql.auto.conf中的违规行，它就修复了一切。

我在 Ubuntu 18.04上使用 PostgreSQL 时遇到过这个问题。

我检查了我的 PostgreSQL状态，发现它运行良好，使用:

sudo systemctl status postgresql

我还尝试使用以下方法重新启动机器上的 PotgreSQL服务器:

sudo systemctl restart postgresql

但问题依然存在:

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"?

在 Noushad 的回答之后，我做了以下 :

列出所有在你的设备上运行的 Postgres 集群:

pg_lsclusters

这给了我这个红色的输出，显示它们都下降了，状态也显示 放下:

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

重新启动其中一个服务器集群的 pg _ ctlcluster:

sudo pg_ctlcluster 10 main start

然而，它抛出了下面的错误，当我尝试重新启动其他 PG 集群时也出现了同样的错误:

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.

检查日志中的错误，在这种情况下，我的是 PG 10:

sudo nano /var/log/postgresql/postgresql-10-main.log

我发现了以下错误:

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.

这是因为我更改了 PostgreSQL 数据目录的文件权限。

我通过运行下面的命令修复了这个问题，我运行了机器上3个 PG 集群的命令:

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

之后，我重新启动了每个 PG 集群:

sudo pg_ctlcluster 10 main start
sudo pg_ctlcluster 11 main start
sudo pg_ctlcluster 12 main start

最后，我再次检查了集群的健康状况:

pg_lsclusters

这次一切都很好，状态显示 在线:

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

仅此而已。

希望这个能帮上忙

在我的例子中，我看到这个错误，postgres 是 没有运行。

问题是安装未能创建所需的集群。

解决方案是创建文件夹 /etc/postgres/{postgresql-version}/main

然后用以下方法创建集群:

pg_createcluster {postgresql-version} main

在那之后，只需重新启动 postgreql 服务，一切都会正常工作。

在我的例子中，出现了这个错误，/var/run/postgresql/.s.PGSQL.5433(注意，在它正在查找的文件 .s.PGSQL.5432之上的一个数字)。试了试页面顶部的说明，但没有任何效果。

原来在 /etc/postgresql/12中有一个用于 PostGreSQL12配置文件的旧目录，我删除了它，从而解决了这个问题。

如果你正在使用 linux 和 Ruby on Rails 的 windows 子系统，那么使用这个命令检查你的 postgres 在哪个端口运行 如果它在端口5433中，那么转到 datase.yml 文件并在其中添加端口: 5433 然后运行命令 sudo service postgresql start 我已经这样解决了我的问题

在我的例子中，在遇到错误之后，以下方法可以用于启动 postgres

sudo service postgresql start
sudo su - postgres
psql

我相信我是在卸载 PostgreSQL 11和12之后陷入这个问题的，当时我已经在 Ubuntu 21上安装了13。我刚用 sudo nano /etc/postgresql/13/main/postgresql.conf解决了这个问题，发现 port = 5433(不知道为什么)。所以我改了 port = 5432。那问题就解决了。

如果您正在使用 WSL 2，请使用以下命令:

sudo service postgresql start

在我的例子中，我卸载了 postgres 10，但是没有成功，一些 pg10文件/进程仍然保留在那里。

然后我安装了 postgres 13，所以 pg 13认为有另一个 pg 在端口5432上运行，所以它使用5433。

解决方案: 通过 sudo apt-get --purge remove postgresql postgresql-*清除你所有的 pg 然后重新安装。(注意: 这将删除所有现有的数据)

这个命令可以在 Ubuntu 机器上使用

Sudo su-postgres

它会要求输入您的密码，很可能是您的默认密码。

这个问题发生在我身上，有时候我们添加一些备份文件夹，日志文件夹，脚本，一些依赖性，如果这不存在，他们可能会导致问题

我知道我的回答太晚了，但我觉得这能帮到别人。

我修改 pg_hba.conf来恢复密码的时候发现了他的问题。我正在运行 Debian GNU/Linux。我是这么做的:

• 将 pg_hba.conf备份到 pg_hba.conf.bk
• 编辑文件
• 重启服务器
• 一切都好

但是，当我想恢复备份文件时:

• 将 pg_hba.conf重命名为 pg_hba.conf_no_pass
• 将 pg_hba.conf.bk重命名为 pg_hba.conf
• 重启服务器
• 我得到了上面的错误。

因此，为了修复这个问题，我将 pg_hba.conf_no_pass重命名为 pg_hba.conf，并像以前一样编辑文件。重新启动服务器后，一切正常。

在 Ubuntu 20.04.4 LTS 中。 我担心套接字连接，因为我在使用:

psql -U postgres db_omm < db.pgsql

错误是: 错误: 连接到套接字“/var/run/postgreql/. s.PGSQL. 5432”上的服务器失败: FATAL: 用户“ postgres”的对等身份验证失败

但身份验证使用用户权限。因此，即使您指定了用户并且位于 root 或其他用户中，也必须切换到 postgres

su - postgres

那就成功了！

在重启服务器的时候，我在两个地方找到了这些

1 postgres postgres 0 Nov 1018:44. s.PGSQL.5432 - rw ——-1 postgres postgres 48 Nov 1018:44. s.PGSQL. 5432. lock

这两个文件都存在于下面的位置，并且在重新启动之前都不存在 /var/run/postgreql/ /tmp/

确保这些具有相应权限的文件可用并启动 psql