无法连接到端口5432上的postgresql
我安装了包含PostgreSQL 8.4的Bitnami Django堆栈 。
当我运行psql -U postgres我收到以下错误：
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肯定在运行， pg_hba.conf文件如下所示：
# 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
是什么赋予了？
pg正在运行的“证据”：
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#
此问题来自安装没有版本号的postgres包。 虽然将安装postgres并且它将是正确的版本，但设置群集的脚本将无法正确运行; 这是一个包装问题。
如果您对postgres感到满意，可以运行一个脚本来创建此集群并运行postgres 。 但是，有一种更简单的方法。
首先清除旧的postgres安装。 目前的问题在于9.1，所以我假设你已经安装了
sudo apt-get remove --purge postgresql-9.1
现在只需重新安装
sudo apt-get install postgresql-9.1
请注意包名称和版本号。 HTH。
错误消息是指Unix域套接字，因此您需要调整netstat调用以排除它们。 所以尝试没有选项-t ：
netstat -nlp | grep 5432
我猜服务器实际上正在侦听socket /tmp/.s.PGSQL.5432而不是客户端尝试连接的/var/run/postgresql/.s.PGSQL.5432 。 这是在Debian或Ubuntu上使用手工编译或第三方PostgreSQL软件包时的典型问题，因为Unix域套接字目录的源默认值为/tmp但Debian打包将其更改为/var/run/postgresql 。
可能的解决方法：
- 使用第三方软件包提供的客户端（调用
/opt/djangostack-1.3-0/postgresql/bin/psql）。 可能完全卸载Ubuntu提供的软件包（由于其他反向依赖性，可能很难）。 - 修复第三方软件包的套接字目录以与Debian / Ubuntu兼容。
- 使用
-H localhost代替通过TCP / IP连接。 - 使用
-h /tmp或等效的PGHOST设置指向正确的目录。 - 不要使用第三方软件包。
您可以使用psql -U postgres -h localhost强制连接通过TCP而不是UNIX域套接字发生; 您的netstat输出显示PostgreSQL服务器正在侦听localhost的端口5432。
您可以通过使用不同的netstat invocavtion找出PostgrSQL服务器使用的本地UNIX套接字：
netstat -lp --protocol=unix | grep postgres
无论如何，PostgreSQL服务器监听的接口都在postgresql.conf中配置。
只需创建一个这样的软链接：
ln -s /tmp/.s.PGSQL.5432 /var/run/postgresql/.s.PGSQL.5432
这对我有用：
编辑：postgresql.conf
sudo nano /etc/postgresql/9.3/main/postgresql.conf
启用或添加：
listen_addresses = '*'
重启数据库引擎：
sudo service postgresql restart
此外，您可以检查文件pg_hba.conf
sudo nano /etc/postgresql/9.3/main/pg_hba.conf
并添加您的网络或主机地址：
host all all 192.168.1.0/24 md5
我不得不在Debian Squeeze上编译PostgreSQL 8.1，因为我使用的是Project Open，它基于OpenACS，不会在更新版本的PostgreSQL上运行。
默认的编译配置将unix_socket放在/tmp ，但是依赖于PostgreSQL的Project Open将无法工作，因为它在/var/run/postgresql查找unix_socket 。
postgresql.conf有一个设置来设置套接字的位置。 我的问题是，我可以设置为/tmp和psql工作，但不是项目打开，或者我可以设置为/var/run/postgresql和psql不起作用，但项目打开。
该问题的一个解决方案是为/var/run/postgresql设置套接字，然后根据Peter的建议运行psql ，如下所示：
psql -h /var/run/postgresql
这使用本地权限在本地运行。 唯一的缺点是它比简单的“psql”更多的输入。
有人提出的另一个建议是在两个地点之间建立一个符号链接。 这也有效，但是重启后链接消失了。 使用-h参数可能更容易，但是，我在/etc/init.d的PostgreSQL脚本中创建了符号链接。 我在“开始”部分放置了symbolic link create命令。 当然，当我发出一个停止并启动或重启命令时，它会尝试重新创建一个现有的符号链接，但除了警告信息之外，可能没有任何损害。
就我而言，而不是：
ln -s /tmp/.s.PGSQL.5432 /var/run/postgresql/.s.PGSQL.5432
我有
ln -s /var/run/postgresql/.s.PGSQL.5432 /tmp/.s.PGSQL.5432
并在postgresql.conf中将unix_socket显式设置为/var/run/postgresql/.s.PGSQL.5432 。
我通过这样做使它工作：
dpkg-reconfigure locales
选择首选语言环境然后运行
pg_createcluster 9.5 main --start
（9.5是我的postgresql版本）
/etc/init.d/postgresql start
然后它的工作原理！
sudo su - postgres psql
解：
做这个
export LC_ALL="en_US.UTF-8"
还有这个。 （ 9.3是我目前的PostgreSQL版本。写下你的版本！）
sudo pg_createcluster 9.3 main --start
在我的情况下，它是由我在编辑/etc/postgresql/9.5/main/pg_hba.conf所做的拼写引起的
我变了：
# Database administrative login by Unix domain socket local all postgres peer
至：
# Database administrative login by Unix domain socket local all postgres MD5
但是MD5必须是小写的md5 ：
# Database administrative login by Unix domain socket local all postgres md5
我用postgres-9.5服务器无法解决这个问题。 经过3天的零进度尝试在这个和其他站点上的每个修复程序，我决定重新安装服务器并失去5天的工作量。 但是，我确实在新实例上复制了这个问题。 这可能会提供一些关于如何解决它的观点，然后再采取我所做的灾难性方法。
首先，禁用postgresql.conf中的所有日志记录设置。 这是部分：
# ERROR REPORTING AND LOGGING
评论该部分中的所有内容。 然后重启服务。
重新启动时，使用/etc/init.d/postgresql start或restart我发现restart处于超级用户模式会很有帮助。 我只为那个操作开了一个x窗口。 您可以使用sudo -i建立超级用户模式。
使用以下简单命令validation是否可以访问服务器： psql -l -U postgres
如果这不能解决问题，请考虑以下事项：
在尝试寻找解决方案时，我正在更改许多文件夹的所有权。 我知道我可能会尝试将这些文件夹所有权和chmod还原2天。 如果您已经搞乱了这些文件夹所有权并且不想完全清除服务器，那么请开始跟踪所有受影响文件夹的设置，以使其恢复到原始状态。 您可能希望尝试在另一个系统上进行并行安装，并系统地检查所有文件夹的所有权和设置。 单调乏味，但您可以访问您的数据。
获得访问权限后，系统地更改postgresql.conf文件的# ERROR REPORTING AND LOGGING部分中的每个相关行。 重启并测试。 我发现日志的默认文件夹导致失败。 我特意注释掉了log_directory 。 系统删除日志的默认文件夹是/var/log/postgresql 。
如果您的Postgres服务启动并运行没有任何错误或启动Postgres服务没有错误，但仍然是您收到上述错误，请按照下列步骤操作
第1 pg_lsclusters ：运行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
最有可能的情况是你的情况下和postgres服务
第2步：重新启动pg_ctlcluster
#format is pg_ctlcluster sudo pg_ctlcluster 9.6 main start #restart postgres sudo service postgres restart
第3步：第2步失败并抛出错误
如果此过程不成功，则会引发错误。 您可以在/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 # 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 postgres restart
我发现卸载Postgres的声音并不令人信服。 这有助于解决我的问题：
-
启动postgres服务器：
sudo systemctl start postgresql -
确保服务器在启动时启动：
sudo systemctl enable postgresql
详细信息可以在DigitalOcean网站上找到。
我有完全相同的问题，彼得Eisentraut描述。 使用netstat -nlp | grep 5432 netstat -nlp | grep 5432命令，我可以看到服务器正在侦听socket /tmp/.s.PGSQL.5432 。
要解决此问题，只需编辑postgresql.conf文件并更改以下行：
listen_addresses = '*' unix_socket_directories = '/var/run/postgresql'
现在运行service postgresql-9.4 restart （用你的版本替换9-4），远程连接现在应该正常工作。
现在要允许本地连接，只需创建一个指向/var/run/postgresql目录的符号链接。
ln -s /var/run/postgresql/.s.PGSQL.5432 /tmp/.s.PGSQL.5432
不要忘记确保你的pg_hba.conf配置正确。
就我而言，我所要做的就是：
sudo service postgresql restart
然后
sudo -u postgres psql
这工作得很好。 希望能帮助到你。 干杯:)。
可能是因为您更改了/var/lib/postgresql/9.3/main文件夹的权限。
尝试使用以下命令将其更改为700：
sudo chmod 700 main
找到你的文件：
sudo find /tmp/ -name .s.PGSQL.5432
结果：
/tmp/.s.PGSQL.5432
以postgres用户身份登录：
su postgres psql -h /tmp/ yourdatabase
我有同样的问题（在Ubuntu 15.10（狡猾））。 sudo find / -name 'pg_hba.conf' -print或sudo find / -name 'postgresql.conf' -print空了。 在此之前，似乎安装了多个postgresql实例。
当您看到已安装或依赖性问题列表时，您可能会有类似的情况
.../postgresql .../postgresql-9.x
等等。
在这种情况下，你必须sudo apt-get autoremove每个包1 1。
然后继续这封信，你会没事的。 特别是在密钥导入和添加到源列表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 -
如果不使用wily，请用你的版本替换lsb_release -cs ，即使用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
然后你应该没事，能够连接和创建用户。
预期产量：
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
我的解决方案的来源（学分）
虽然有同样的问题我尝试了不同的东西：
我手动启动postgresql守护进程：
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.
所以我所做的是将shared_buffers和max_connections下限设置为postgresql.conf并restart服务。
这解决了这个问题！
这是完整的错误日志：
$ 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.