Не удается подключиться к postgresql через порт 5432

Я установил стек Bitnami Django, который включал PostgreSQL 8.4.

При запуске 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

Запишите название пакета с номером версии. НТН.

Сообщение об ошибке относится к сокету Unix-домена, поэтому вам нужно настроить netstatвызов, чтобы не исключать их. Так что попробуйте без опции -t:

netstat -nlp | grep 5432

Я предполагаю, что сервер на самом деле слушает сокет, /tmp/.s.PGSQL.5432а не тот /var/run/postgresql/.s.PGSQL.5432, к которому ваш клиент пытается подключиться. Это типичная проблема при использовании скомпилированных вручную или сторонних пакетов PostgreSQL в Debian или Ubuntu, потому что исходным по умолчанию для каталога сокетов Unix-домена является, /tmpно пакет Debian меняет его на /var/run/postgresql.

Возможные обходные пути:

• Используйте клиентов, предоставленных вашим сторонним пакетом (звонок /opt/djangostack-1.3-0/postgresql/bin/psql). Возможно, удалите все пакеты, поставляемые с Ubuntu (это может быть сложно из-за других обратных зависимостей).
• Исправьте каталог сокетов стороннего пакета, чтобы он был совместим с Debian / Ubuntu.
• -H localhostВместо этого используйте для подключения через TCP / IP.
• Используйте -h /tmpили эквивалентную PGHOSTнастройку, чтобы указать на правильный каталог.
• Не используйте сторонние пакеты.

Это работает для меня:

Изменить: 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

Вы можете использовать, psql -U postgres -h localhostчтобы заставить соединение происходить по TCP вместо доменных сокетов UNIX; ваш netstatвывод показывает, что сервер PostgreSQL прослушивает порт 5432 локального хоста.

Вы можете узнать, какой локальный сокет UNIX используется сервером PostgrSQL, используя другой вызов netstat :

netstat -lp --protocol=unix | grep postgres

В любом случае, интерфейсы, на которых слушает сервер PostgreSQL, настроены в postgresql.conf.

Просто создайте мягкую ссылку, подобную этой:

ln -s /tmp/.s.PGSQL.5432 /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

Мне пришлось скомпилировать PostgreSQL 8.1 на Debian Squeeze, потому что я использую Project Open, который основан на OpenACS и не будет работать на более поздних версиях PostgreSQL.

Конфигурация компиляции по умолчанию помещает unix_socketв систему /tmp, но проект Open, который основывается на PostgreSQL, не будет работать , так как это выглядит для unix_socketна /var/run/postgresql.

Есть настройка, postgresql.confчтобы установить местоположение сокета. Моя проблема заключалась в том, что либо я мог установить /tmpи psqlработать, но не открыть проект, либо я мог установить его /var/run/postgresqlи psqlне работать, но открытие проекта сделало.

Одно из решений этой проблемы состоит в том, чтобы установить сокет для /var/run/postgresqlи затем запустить psql, основываясь на предложении Питера, как:

psql -h /var/run/postgresql

Это выполняется локально с использованием локальных разрешений. Единственным недостатком является то, что он больше печатает, чем просто "psql".

Другое предложение, которое сделал кто-то, состояло в том, чтобы создать символическую связь между этими двумя местоположениями. Это также сработало, но ссылка исчезла после перезагрузки. Возможно, проще использовать аргумент -h, однако я создал символическую ссылку из скрипта PostgreSQL /etc/init.d. Я разместил символическую команду создания ссылки в разделе «Пуск». Конечно, когда я запускаю команду остановки и запуска или перезапуска, она будет пытаться воссоздать существующую символическую ссылку, но, кроме предупреждающего сообщения, в этом нет никакого вреда.

В моем случае вместо:

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

у меня есть

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

и явно установить unix_socket /var/run/postgresql/.s.PGSQL.5432в postgresql.conf.

Решение:

Сделай это

export LC_ALL="en_US.UTF-8"

и это. ( 9.3 - это моя текущая версия PostgreSQL. Напишите свою версию!)

sudo pg_createcluster 9.3 main --start

Если ваша служба Postgres запущена и работает без каких-либо ошибок или при запуске службы 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

Скорее всего, статус будет ниже в вашем случае и сервис Postgres

Шаг 2: перезапустите pg_ctlcluster

#format is pg_ctlcluster <version> <cluster> <action>
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

Оказалось, что я ошибочно удалил пользователя Postgres из ssl-certгруппы. Запустите приведенный ниже код, чтобы исправить проблему группы пользователей и исправить разрешения

#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

В моем случае это было вызвано опечаткой, которую я сделал при редактировании /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 звучит неубедительно. Это помогает решить мою проблему:

1. Запустите сервер postgres:

   sudo systemctl start postgresql
   

2. Убедитесь, что сервер запускается при загрузке:

   sudo systemctl enable postgresql
   

Подробную информацию можно найти на сайте DigitalOcean здесь.

Я не смог решить эту проблему с моим сервером postgres-9.5. После 3 дней нулевого прогресса, пробуя каждую перестановку исправлений на этом и других сайтах, я решил переустановить сервер и потерять 5 дней работы. Но я повторил проблему на новом экземпляре. Это может дать некоторое представление о том, как это исправить, прежде чем использовать катастрофический подход, который я сделал.

Во-первых, отключите все параметры ведения журнала в postgresql.conf. Это раздел:

# ERROR REPORTING AND LOGGING

Закомментируйте все в этом разделе. Затем перезапустите сервис.

При перезапуске используйте /etc/init.d/postgresql start или restart я нашел полезным находиться в режиме суперпользователя при перезапуске. У меня было открыто окно x только для этой операции. Вы можете установить этот режим суперпользователя с помощью sudo -i.

Убедитесь, что к серверу можно подключиться с помощью этой простой команды: psql -l -U postgres

Если это не помогает, то подумайте:

Я менял владельца многих папок, пытаясь найти решение. Я знал, что я, вероятно, буду пытаться вернуть владельцам этих папок еще chmodдва дня. Если вы уже перепутали владельцев этих папок и не хотите полностью очищать свой сервер, начните отслеживать настройки всех затронутых папок, чтобы вернуть их в исходное состояние. Возможно, вы захотите попробовать выполнить параллельную установку в другой системе и систематически проверять владение и настройки всех папок. Утомительно, но вы можете получить доступ к своим данным.

Получив доступ, систематически изменяйте каждую соответствующую строку в # ERROR REPORTING AND LOGGINGразделе postgresql.confфайла. Перезапустите и проверьте. Я обнаружил, что папка по умолчанию для журналов вызывает сбой. Я специально закомментировал log_directory. Папка по умолчанию, в которую система удаляет журналы, - это /var/log/postgresql.

Возможно, это могло произойти, потому что вы изменили права доступа к /var/lib/postgresql/9.3/mainпапке.

Попробуйте изменить его на 700, используя команду ниже:

sudo chmod 700 main

Это не совсем связано с вопросом, так как я использую Flask, но это была именно та ошибка, которую я получил, и это была самая важная тема для получения идей.

Моя установка: подсистема Windows для Linux, Docker-compose с make-файлом с dockerfile, Flask, Postgresql (с использованием схемы, состоящей из таблиц)

Чтобы подключиться к postgres, настройте строку подключения следующим образом:

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

ПРИМЕЧАНИЕ. У меня никогда не было IP-адреса (например, localhost, 127.0.0.1) для работы с использованием какого-либо метода в этой теме. Идея использования имени контейнера вместо localhost пришла отсюда: https://github.com/docker-library/postgres/issues/297

Установите вашу схему:

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

Задайте путь поиска для своих функций при настройке сеанса:

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

У меня была та же самая проблема, которую описал Питер Эйзентро. Используя netstat -nlp | grep 5432команду, я увидел, что сервер прослушивает сокет /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

Это работало просто отлично. Надеюсь, это поможет. Ура :).

Найдите свой файл:

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.

Тогда следуйте этому письму и у вас все будет хорошо. Особенно когда речь идет об импорте ключей и добавлении их в список источников.

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

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.

После многих изнурительных попыток я нашел решение, основанное на других постах!

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

Создайте каталог postgresql внутри run и затем выполните следующую команду.

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

Просто добавьте / tmp unix_socket_directories

postgresql.conf

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