Nie można połączyć się z postgresql na porcie 5432

Zainstalowałem stos Bitnami Django, który zawierał PostgreSQL 8.4.

Po uruchomieniu psql -U postgrespojawia się następujący błąd:

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 na pewno działa, a pg_hba.confplik wygląda następująco:

# 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

Co daje?

„Dowód”, że pg działa:

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# 

Ten problem pochodzi z instalacji postgrespakietu bez numeru wersji. Chociaż postgreszostanie zainstalowany i będzie to poprawna wersja, skrypt do konfiguracji klastra nie będzie działał poprawnie; to kwestia pakowania.

Jeśli nie masz nic postgresprzeciwko, możesz utworzyć skrypt i uruchomić ten klaster postgres. Istnieje jednak prostszy sposób.

Najpierw wyczyść starą instalację Postgres. Problem leży obecnie w wersji 9.1, więc założę, że właśnie to zainstalowałeś

sudo apt-get remove --purge postgresql-9.1

Teraz po prostu zainstaluj ponownie

sudo apt-get install postgresql-9.1

Zanotuj nazwę pakietu wraz z numerem wersji. HTH.

Komunikat o błędzie odnosi się do gniazda w domenie Uniksa, więc musisz dostosować swoje netstatwywołanie, aby ich nie wykluczyć. Wypróbuj więc bez opcji -t:

netstat -nlp | grep 5432

Domyślam się, że serwer faktycznie nasłuchuje na gnieździe, /tmp/.s.PGSQL.5432a nie ten /var/run/postgresql/.s.PGSQL.5432, z którym klient próbuje się połączyć. Jest to typowy problem w przypadku korzystania z ręcznie skompilowanych lub innych pakietów PostgreSQL na Debianie lub Ubuntu, ponieważ domyślnym źródłem źródłowego katalogu gniazd w domenie Unix jest to, że pakiet Debian /tmpgo zmienia /var/run/postgresql.

Możliwe obejścia:

• Skorzystaj z klientów dostarczonych przez pakiet innej firmy (połączenie /opt/djangostack-1.3-0/postgresql/bin/psql). Ewentualnie całkowicie odinstaluj pakiety dostarczone przez Ubuntu (może to być trudne z powodu innych zależności odwrotnych).
• Napraw katalog gniazda pakietu innej firmy, aby był zgodny z Debian / Ubuntu.
• -H localhostZamiast tego użyj do połączenia przez TCP / IP.
• Użyj -h /tmplub równoważne PGHOSTustawienie, aby wskazać właściwy katalog.
• Nie używaj pakietów innych firm.

To działa dla mnie:

Edycja: postgresql.conf

sudo nano /etc/postgresql/9.3/main/postgresql.conf

Włącz lub dodaj:

listen_addresses = '*'

Uruchom ponownie silnik bazy danych:

sudo service postgresql restart

Możesz także sprawdzić plik pg_hba.conf

sudo nano /etc/postgresql/9.3/main/pg_hba.conf

I dodaj adres sieci lub hosta:

host    all             all             192.168.1.0/24          md5

Możesz użyć, psql -U postgres -h localhostaby wymusić połączenie przez TCP zamiast gniazd domeny UNIX; twoje netstatdane wyjściowe pokazują, że serwer PostgreSQL nasłuchuje na porcie 5432 hosta lokalnego.

Możesz dowiedzieć się, które lokalne gniazdo UNIX jest używane przez serwer PostgrSQL, korzystając z innego wywołania netstat :

netstat -lp --protocol=unix | grep postgres

W każdym razie skonfigurowane są interfejsy, na których nasłuchuje serwer PostgreSQL postgresql.conf.

Wystarczy utworzyć taki softlink:

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

Sprawiam, że działa tak:

dpkg-reconfigure locales

Wybierz preferowane ustawienia regionalne, a następnie uruchom

pg_createcluster 9.5 main --start

(9.5 to moja wersja postgresql)

/etc/init.d/postgresql start

i wtedy to działa!

sudo su - postgres
psql

Musiałem skompilować PostgreSQL 8.1 na Debian Squeeze, ponieważ używam Project Open, który jest oparty na OpenACS i nie będzie działał na nowszych wersjach PostgreSQL.

Domyślna konfiguracja kompilacji stawia unix_socketin /tmp, ale projekt open, która opiera się na PostgreSQL, nie będzie działać, ponieważ wygląda dla unix_socketco /var/run/postgresql.

Jest ustawienie w, postgresql.confaby ustawić lokalizację gniazda. Mój problem polegał na tym, że albo mogłem ustawić /tmpi psqlpracować, ale projekt nie był otwarty, lub mogłem ustawić /var/run/postgresqli psqlnie działał, ale projekt był otwarty.

Jednym z rozwiązań tego problemu jest ustawienie gniazda dla, /var/run/postgresqla następnie uruchomienie psql, zgodnie z sugestią Piotra, jako:

psql -h /var/run/postgresql

Działa to lokalnie przy użyciu uprawnień lokalnych. Jedyną wadą jest to, że piszą więcej niż po prostu „psql”.

Inną sugestią, którą ktoś zaproponował, było utworzenie symbolicznego połączenia między dwiema lokalizacjami. To również działało, ale link zniknął po ponownym uruchomieniu. Być może łatwiej jest po prostu użyć argumentu -h, jednak utworzyłem dowiązanie symboliczne ze skryptu PostgreSQL w /etc/init.d. Umieściłem polecenie tworzenia łącza symbolicznego w sekcji „start”. Oczywiście, kiedy wydam polecenie stop i start lub restart, spróbuje odtworzyć istniejące dowiązanie symboliczne, ale oprócz komunikatu ostrzegawczego prawdopodobnie nie ma w tym żadnej szkody.

W moim przypadku zamiast:

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

mam

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

i jawnie ustawiłem unix_socket na /var/run/postgresql/.s.PGSQL.5432in postgresql.conf.

Rozwiązanie:

Zrób to

export LC_ALL="en_US.UTF-8"

i to. ( 9.3 to moja aktualna wersja PostgreSQL. Napisz swoją wersję!)

sudo pg_createcluster 9.3 main --start

Jeśli Twoja usługa Postgres działa bezbłędnie lub nie ma błędu podczas uruchamiania usługi Postgres i nadal pojawia się wspomniany błąd, wykonaj następujące kroki

Krok 1: Uruchomienie pg_lsclusterswyświetli listę wszystkich klastrów Postgres działających na twoim urządzeniu

na przykład:

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

najprawdopodobniej status spadnie w twoim przypadku i usłudze postgres

Krok 2: Uruchom ponownie pg_ctlcluster

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

#restart postgres
sudo service postgres restart

Krok 3: Krok 2 nie powiódł się i zgłosił błąd

Jeśli ten proces się nie powiedzie, wygeneruje błąd. Możesz zobaczyć błąd logowania/var/log/postgresql/postgresql-9.6-main.log

Mój błąd to:

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`

Krok 4: sprawdź własność postgres

Upewnij się, że postgresjest właścicielem/var/lib/postgresql/version_no/main

Jeśli nie, uruchom

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

Krok 5: Sprawdź, czy użytkownik postgres należy do grupy użytkowników ssl-cert

Okazało się, że błędnie usunąłem użytkownika Postgres z ssl-certgrupy. Uruchom poniższy kod, aby naprawić problem z grupą użytkowników i naprawić uprawnienia

#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

W moim przypadku było to spowodowane literówką, którą popełniłem podczas edycji /etc/postgresql/9.5/main/pg_hba.conf

Zmieniłam:

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

do:

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

Ale MD5musiało być pisane małymi literami md5:

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

Odkryłem, że odinstalowanie Postgres brzmi nieprzekonująco. Pomaga to rozwiązać mój problem:

1. Uruchom serwer Postgres:

   sudo systemctl start postgresql
   

2. Upewnij się, że serwer uruchamia się przy rozruchu:

   sudo systemctl enable postgresql
   

Szczegółowe informacje można znaleźć na stronie DigitalOcean tutaj.

Nie udało mi się rozwiązać tego problemu na moim serwerze postgres-9.5. Po 3 dniach zerowego postępu, wypróbowując każdą permutację poprawki na tej i innych stronach, zdecydowałem się ponownie zainstalować serwer i stracić 5 dni pracy. Ale powtórzyłem problem w nowej instancji. To może dać pewne spojrzenie na to, jak to naprawić, zanim zastosujesz katastroficzne podejście, które zrobiłem.

Najpierw wyłącz wszystkie ustawienia rejestrowania w postgresql.conf. To jest sekcja:

# ERROR REPORTING AND LOGGING

Skomentuj wszystko w tej sekcji. Następnie uruchom ponownie usługę.

Podczas ponownego uruchamiania użyj /etc/init.d/postgresql start lub restart uważam, że pomocne było przejście do trybu superużytkownika podczas ponownego uruchamiania. Miałem otwarte okno X tylko dla tej operacji. Możesz ustawić ten tryb administratora za pomocą sudo -i.

Sprawdź, czy serwer jest dostępny za pomocą tego prostego polecenia: psql -l -U postgres

Jeśli to nie rozwiąże problemu, rozważ to:

Zmieniłem właściciela wielu folderów, próbując znaleźć rozwiązanie. Wiedziałem, że prawdopodobnie będę próbował cofnąć prawa własności do folderów chmodprzez 2 kolejne dni. Jeśli pomieszałeś już z tymi własnościami folderów i nie chcesz całkowicie wyczyścić serwera, zacznij śledzić ustawienia wszystkich folderów, których dotyczy problem, aby przywrócić je do pierwotnego stanu. Możesz spróbować wykonać równoległą instalację w innym systemie i systematycznie sprawdzać własność i ustawienia wszystkich folderów. Nużący, ale możesz mieć dostęp do swoich danych.

Po uzyskaniu dostępu należy systematycznie zmieniać każdą odpowiednią linię w # ERROR REPORTING AND LOGGINGsekcji postgresql.confpliku. Uruchom ponownie i przetestuj. Odkryłem, że domyślny folder dzienników powodował awarię. Szczególnie skomentowałem log_directory. Domyślny folder, w którym system upuszcza logi, to /var/log/postgresql.

Możliwe, że tak się stało, ponieważ zmieniłeś uprawnienia do /var/lib/postgresql/9.3/mainfolderu.

Spróbuj zmienić go na 700 za pomocą poniższego polecenia:

sudo chmod 700 main

To nie jest dokładnie związane z pytaniem, ponieważ używam Flask, ale to był dokładnie ten błąd, który otrzymywałem i był to najbardziej odpowiedni wątek do zdobywania pomysłów.

Moja konfiguracja: Windows Subsystem for Linux, Docker-compose w / makefile w / dockerfile, Flask, Postgresql (używając schematu składającego się z tabel)

Aby połączyć się z postgres, skonfiguruj parametry połączenia w następujący sposób:

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

UWAGA: Nigdy nie dostałem żadnego adresu IP (np. Localhost, 127.0.0.1) do pracy przy użyciu dowolnej metody w tym wątku. Pomysł użycia nazwy kontenera zamiast localhost zrodził się stąd: https://github.com/docker-library/postgres/issues/297

Ustaw swój schemat:

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

Podczas konfigurowania sesji ustaw ścieżkę wyszukiwania funkcji:

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

Miałem dokładnie ten sam problem, który opisał Peter Eisentraut. Za pomocą netstat -nlp | grep 5432polecenia mogłem zobaczyć, że serwer nasłuchuje na gnieździe /tmp/.s.PGSQL.5432.

Aby to naprawić, po prostu edytuj postgresql.confplik i zmień następujące linie:

listen_addresses = '*'
unix_socket_directories = '/var/run/postgresql'

Teraz uruchom service postgresql-9.4 restart(Zastąp 9-4 wersją), a połączenia zdalne powinny już działać.

Teraz, aby zezwolić na połączenia lokalne, po prostu utwórz symboliczne łącze do /var/run/postgresqlkatalogu.

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

Nie zapomnij upewnić się, że twój też pg_hba.confjest poprawnie skonfigurowany.

W moim przypadku wszystko, co musiałem zrobić, to:

sudo service postgresql restart

i wtedy

sudo -u postgres psql

To działało dobrze. Mam nadzieję, że to pomoże. Twoje zdrowie :) .

Znajdź swój plik:

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

Wynik:

/tmp/.s.PGSQL.5432

Zaloguj się jako użytkownik postgres:

su postgres
psql -h /tmp/ yourdatabase

Miałem ten sam problem (na Ubuntu 15.10 (przebiegły)). sudo find / -name 'pg_hba.conf' -printlub sudo find / -name 'postgresql.conf' -printokazało się puste. Wcześniej wydawało się, że zainstalowano wiele instancji postgresql.

Możesz mieć podobne, gdy widzisz jako zainstalowane, lub listę problemów z zależnościami

.../postgresql
.../postgresql-9.x 

i tak dalej.

W takim przypadku musisz sudo apt-get autoremovekażdy pakiet 1 na 1.

Następnie postępuj zgodnie z listem i wszystko będzie dobrze. Zwłaszcza jeśli chodzi o PIERWSZE importowanie i dodawanie kluczy do listy źródeł

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 -

Jeśli nie używasz podstępnie, zamień na wilyswoje wydanie, tj. Na wyjścielsb_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

A potem powinieneś być w porządku i móc łączyć się i tworzyć użytkowników.

Oczekiwany wynik:

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

Źródło moich rozwiązań (kredyty)

Mając ten sam problem, próbowałem czegoś innego:

Uruchamiając ręcznie demona postgresql, otrzymałem:

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.

Więc to, co zrobiłem, było ustawienie dolnego limitu dla shared_buffersi max_connectionsdo postgresql.confi restartusługi.

To naprawiło problem!

Oto pełny dziennik błędów:

$ 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.

Po wielu wyczerpujących próbach znalazłem rozwiązanie oparte na innych postach!

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

Utwórz katalog postgresql w trakcie uruchamiania, a następnie uruchom następującą komendę.

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

Po prostu dodaj / tmp unix_socket_directories

postgresql.conf

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