Почему PSQL не может подключиться к серверу?
Я набрал psql и я получаю это:
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"?
я использовал sudo netstat -nlp | grep 5432 чтобы увидеть статус, но ничего не показал. И я искал в Интернете, кто-то сказал мне, чтобы изменить pg_hba.conf но я не могу locate этот файл. И я тоже попробовал эту командуsudo ln -s /tmp/.s.PGSQL.5432 /var/run/postgresql/.s.PGSQL.5432, Это не может работать.
38 ответов
В сообщении об ошибке говорится, что утилита 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.
Если при запуске службы 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
# 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 postgres restart
У меня возникла эта проблема при работе с PostgreSQL в Ubuntu 18.04.
Я проверил свой
PostgreSQL status и понял, что все работает нормально, используя:
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"?
После ответа Нушада я сделал следующее:
Перечислите все кластеры Postgres, запущенные на вашем устройстве:
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
на этот раз все снова было хорошо, как показывает статус в Интернете:
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 после появления ошибки работало следующее:
sudo service postgresql start
sudo su - postgres
psql
Я сталкивался с подобной проблемой пару раз. Обычно я просто делаю новую установку PostgreSQL, следуя этому руководству, и это решает проблему за счет потери данных.
Я был полон решимости получить настоящее решение сегодня. Перезапуск PostgreSQL разрешил это в Ubuntu. sudo /etc/init.d/postgresql restart
Если вы используете WSL 2, используйте это:
sudo service postgresql start
Я столкнулся с той же проблемой и
sudo su - postgres
initdb --locale en_US.UTF-8 -D /var/lib/postgres/data
exit
sudo systemctl start postgresql
sudo systemctl status postgresql
Это сработало для меня.
Решил это! Хотя я не знаю, что случилось, но я просто удалил все вещи и переустановил их. Это команда, которую я использовал, чтобы удалить его sudo apt-get --purge remove postgresql\* а также dpkg -l | grep postgres, Последний - найти все пакеты, если они не чистые.
Краткое руководство по Debian:
- редактировать
/etc/postgresql/10/main/postgresql.confс адресом прослушивания * - редактировать
/etc/postgresql/10/main/pg_hba.confи добавьте строку в концеhost all all 0/0 md5 - создать роль входа
postgres=# CREATE ROLE remoteuser LOGIN WITH PASSWORD 'foo' sudo /etc/init.d/postgresql restartизменения вступают в силувойти с клиентской стороны с
psql --host=ipofserver --port=5432 --username=remoteuser --password --dbname=mydb- пароль интерактивно спрашивается, который в этом случае foo
вот как получить удаленный доступ к базе данных postgres на сервере из клиента psql
Я решил эту проблему, проверив, что моя файловая система полностью заполнена, поэтому база данных не может запуститься
соединения на доменном сокете Unix "/var/run/postgresql/.s.PGSQL.5432" ?
Я пробовал серию устранения неполадок до тех пор, пока я не проверил использование моего диска и не обнаружил, что оно заполнено, 100% использование
df -h
cd /var/log/odoo/
cat /dev/null > odoo-server.log
reboot
В Ubuntu 20.04.4 LTS. Меня беспокоило подключение к сокету, потому что я использовал:
psql -U postgres db_omm < db.pgsql
и ошибка была: Ошибка: соединение с сервером в сокете "/var/run/postgresql/.s.PGSQL.5432" не удалось: FATAL: Ошибка одноранговой аутентификации для пользователя "postgres"
Но аутентификация использует права пользователя. Так что даже если вы укажете пользователя и находитесь в root или другом, вам нужно переключиться на postgres
su - postgres
Тогда это сработало!
Я полагаю, что столкнулся с этой проблемой после удаления PostgreSQL 11 и 12, хотя уже установил 13 на Ubuntu 21. Я решил эту проблему, выполнив
sudo nano /etc/postgresql/13/main/postgresql.conf, и обнаружил, что
port = 5433(не знаю почему). Итак, я изменил
port = 5432. Тогда проблема решена.
если вы используете подсистему Windows для Linux и Ruby on Rails, проверьте, на каком порту работает ваш postgres, с помощью этой команды
sudo nano /etc/postgresql/12/main/postgresql.conf если он находится в порту 5433, перейдите в файл database.yml и добавьте туда порт:5433, а затем запустите команду
sudo service postgresql start я решил свою проблему вот так
Ошибка означает, что сервер 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, где большинство клиентов смотрят по умолчанию, исправил это для меня.
Хорошо, в моем случае я удалил postgres 10, но не успешно, какой-то файл/процесс pg10 все еще остается там.
а затем я установил postgres 13, поэтому pg 13 думает, что есть еще один pg, работающий на порту 5432, поэтому он использует 5433.
решение: очистите все ваши pg через:
sudo apt-get --purge remove postgresql postgresql-*а затем переустановите его. (предупреждение: это удалит все ваши существующие данные)
Из командной строки выполните:pg_isready
> pg_isready
/run/postgresql:5432 - accepting connections
Это покажет, подключен ли postgresql к локальному сокету и принимает соединения.
URI соединения :
"host=/run/postgresql dbname=your_db_name"
должно работать для клиентов, пытающихся подключиться локально.
У меня такая же проблема. Кажется, что нет сокета, когда нет кластера.
Не удалось создать кластер по умолчанию во время установки, поскольку не задан языковой стандарт по умолчанию.
Моя проблема с этим сообщением об ошибке была в неправильных разрешениях на ключе и сертификатах pem, которыми я манипулировал. Что мне очень помогло, так это: /var/log/postgresql/postgresql-9.5-main.log, где все ошибки.
Мне пришлось настроить учетные данные в файле config/database.yml в базе данных по умолчанию.
username: <%= ENV["PG_USERNAME"] %>
password: <%= ENV["PG_PASSWORD"] %>
В моем случае у меня была эта ошибка,
/var/run/postgresql/.s.PGSQL.5433 (обратите внимание, на один номер выше из файла, который он искал,
.s.PGSQL.5432) присутствовал. Пробовал выполнять инструкции вверху этой страницы, но ничего не помогло.
Оказывается, был старый каталог для файлов конфигурации PostGreSQL 12 в
/etc/postgresql/12, который я удалил, что решило проблему.
Убедитесь, что 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 и это сработало.
В моем случае служба работала, но кластер не работал, и 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, он все исправил.
Во время свежей установки postgresql. По умолчанию имя пользователя и пароль назначаются как "postgres". Функция, предоставляемая этой СУБД, заключается в добавлении роли для нового пользователя и создании базы данных. Если вы получаете такие ошибки:
войти в систему по умолчанию имя пользователя:
root @ kalilinux: ~ # sudo -i -u postgres
ype psql для интерактивного приглашения
postgres@kalilinux:~$ psql
Выйти из быстрого использования
\ д
Создать новую роль пользователя
postgres@kalilinux:~$ createuser --interactive
Теперь вы находитесь в интерактивной оболочке PSQL. Наслаждаться. Не забудьте войти под своим именем пользователя и набрать psql для shell.
Это может вызвать что угодно, например, моя проблема была вызвана ошибкой опечатки в файлах конфигурации. Некоторые люди говорят, что это вызвано файлами сертификатов, другая группа говорит, что это вызвано непревзойденными местными жителями.
Если вы не можете найти решение по вашей проблеме, удалите postgres и переустановите его. Это лучшее решение.
Просто хочу сделать небольшое дополнение: если ваш экземпляр жалуется на сокет, вы также можете проверить unix_socket_directories в /data/postgresql.conf файл, который мог быть установлен в /tmpНапример, если вы использовали сторонний дистрибутив. Вы можете изменить его на /var/run/postgresql и перезапустите сервис. Это также может потребовать создания postgresql режиссёр в /var/run а также subsys/postgresql-9.6 в /var/lock если таковых еще не существует (работал для меня с postgresql 9.6).
В моем случае я видел эту ошибку, и postgres не работал.
Проблема заключалась в том, что при установке не удалось создать требуемый кластер.
Решением было создать папку
/etc/postgres/{postgresql-version}/main
а затем создайте кластер с помощью:
pg_createcluster {postgresql-version} main
После этого после перезапуска службы postgresql все должно работать.
В некоторых случаях помогает:
rm /usr/local/var/postgres/postmaster.pid
brew services restart postgresql
sudo systemctl запустить postgresql
эта команда помогает мне однажды, когда я сталкиваюсь с такой проблемой
Если ваш сервис небезопасен, это может быть причиной
vi /etc/postgresql/11/main/pg_hba.conf- откройте файл конфигурации hba, этот файл конфигурации обычно находится в каталоге etc.
host all all localhost trust md5вы можете удалить ключевое слово доверия
сохранить pg_hba.conf
- sudo service postgresql restart.