Impossibile connettersi a postgresql sulla porta 5432

Ho installato lo stack Bitnami Django che includeva PostgreSQL 8.4.

Quando corro psql -U postgresottengo il seguente errore:

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 è sicuramente in esecuzione e il pg_hba.conffile è simile al seguente:

# 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

Cosa dà?

"Prova" che pg sta eseguendo:

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# 

Questo problema deriva dall'installazione del postgrespacchetto senza un numero di versione. Sebbene postgresverrà installato e sarà la versione corretta, lo script per configurare il cluster non verrà eseguito correttamente; è un problema di imballaggio.

Se hai dimestichezza postgresc'è uno script che puoi eseguire per creare questo cluster e iniziare postgres. Tuttavia, c'è un modo più semplice.

Per prima cosa eliminare la vecchia installazione di Postgres. Il problema si trova attualmente con 9.1, quindi suppongo che sia quello che hai installato

sudo apt-get remove --purge postgresql-9.1

Ora reinstalla semplicemente

sudo apt-get install postgresql-9.1

Nota il nome del pacchetto con il numero di versione. HTH.

Il messaggio di errore si riferisce a un socket di dominio Unix, quindi è necessario modificare la propria netstatchiamata per non escluderli. Quindi provalo senza l'opzione -t:

netstat -nlp | grep 5432

Immagino che il server sia effettivamente in ascolto sul socket /tmp/.s.PGSQL.5432anziché su quello a cui il /var/run/postgresql/.s.PGSQL.5432tuo client sta tentando di connettersi. Questo è un problema tipico quando si usano pacchetti PostgreSQL compilati a mano o di terze parti su Debian o Ubuntu, perché il valore predefinito di origine per la directory socket del dominio Unix è /tmpma il pacchetto Debian lo cambia /var/run/postgresql.

Possibili soluzioni:

• Utilizzare i client forniti dal pacchetto di terze parti (chiamata /opt/djangostack-1.3-0/postgresql/bin/psql). Possibilmente disinstallare del tutto i pacchetti forniti da Ubuntu (potrebbe essere difficile a causa di altre dipendenze inverse).
• Correggi la directory socket del pacchetto di terze parti in modo che sia compatibile con Debian / Ubuntu.
• Utilizzare invece -H localhostper connettersi tramite TCP / IP.
• Utilizzare un'impostazione -h /tmpequivalente PGHOSTper puntare alla directory corretta.
• Non utilizzare pacchetti di terze parti.

Questo funziona per me:

Modifica: postgresql.conf

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

Abilita o aggiungi:

listen_addresses = '*'

Riavvia il motore di database:

sudo service postgresql restart

Inoltre, puoi controllare il file pg_hba.conf

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

E aggiungi il tuo indirizzo di rete o host:

host    all             all             192.168.1.0/24          md5

È possibile utilizzare psql -U postgres -h localhostper forzare la connessione su TCP anziché socket di dominio UNIX; l' netstatoutput mostra che il server PostgreSQL è in ascolto sulla porta 5432 di localhost.

È possibile scoprire quale socket UNIX locale viene utilizzato dal server PostgrSQL utilizzando un diverso invocavtion di netstat :

netstat -lp --protocol=unix | grep postgres

Ad ogni modo, le interfacce su cui il server PostgreSQL ascolta sono configurate postgresql.conf.

Basta creare un softlink come questo:

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

Lo faccio funzionare facendo questo:

dpkg-reconfigure locales

Scegli le tue localizzazioni preferite quindi esegui

pg_createcluster 9.5 main --start

(9.5 è la mia versione di postgresql)

/etc/init.d/postgresql start

e poi funziona!

sudo su - postgres
psql

Ho dovuto compilare PostgreSQL 8.1 su Debian Squeeze perché sto usando Project Open, che è basato su OpenACS e non funzionerà su versioni più recenti di PostgreSQL.

La configurazione di compilazione predefinita inserisce unix_socketin /tmp, ma Project Open, che si basa su PostgreSQL, non funzionerebbe perché cerca l' unix_socketat /var/run/postgresql.

C'è un'impostazione postgresql.confper impostare la posizione del socket. Il mio problema era che o avrei potuto impostare /tmpe psqllavorare, ma non aprire il progetto, oppure avrei potuto impostarlo /var/run/postgresqle psqlnon avrebbe funzionato, ma il progetto era aperto.

Una soluzione al problema è impostare il socket per /var/run/postgresqle quindi eseguire psql, in base al suggerimento di Peter, come:

psql -h /var/run/postgresql

Questo viene eseguito localmente utilizzando le autorizzazioni locali. L'unico inconveniente è che si tratta di scrivere più di un semplice "psql".

L'altro suggerimento che qualcuno ha fatto è stato quello di creare un collegamento simbolico tra le due posizioni. Anche questo ha funzionato, ma il collegamento è scomparso al riavvio. Forse è più semplice usare l'argomento -h, tuttavia, ho creato il collegamento simbolico all'interno dello script PostgreSQL in /etc/init.d. Ho inserito il comando simbolico create create nella sezione "start". Ovviamente, quando invio un comando di arresto e avvio o riavvio, proverò a ricreare un collegamento simbolico esistente, ma a parte il messaggio di avviso, probabilmente non vi è alcun danno.

Nel mio caso, invece di:

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

io ho

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

e ho impostato esplicitamente unix_socket su /var/run/postgresql/.s.PGSQL.5432in postgresql.conf.

Soluzione:

Fai questo

export LC_ALL="en_US.UTF-8"

e questo. ( 9.3 è la mia attuale versione di PostgreSQL. Scrivi la tua versione!)

sudo pg_createcluster 9.3 main --start

Se il tuo servizio Postgres è attivo e funzionante senza errori o non c'è nessun errore nell'avvio del servizio Postgres e stai ancora riscontrando l'errore indicato, segui questi passaggi

Step1: Running pg_lsclusterselenca tutti i cluster di Postgres in esecuzione sul tuo dispositivo

per esempio:

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

molto probabilmente lo stato sarà inattivo nel tuo caso e nel servizio postgres

Passaggio 2: riavviare pg_ctlcluster

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

#restart postgres
sudo service postgres restart

Passaggio 3: passaggio 2 non riuscito e generato errore

Se questo processo non ha esito positivo, verrà generato un errore. È possibile visualizzare il log degli errori/var/log/postgresql/postgresql-9.6-main.log

Il mio errore è stato:

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`

Passaggio 4: verifica la proprietà di Postgres

Assicurati che postgressia il proprietario di/var/lib/postgresql/version_no/main

Altrimenti, scappa

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

Passaggio 5: verificare che l'utente postgres appartenga al gruppo utenti ssl-cert

Si è scoperto che avevo rimosso erroneamente l'utente Postgres dal ssl-certgruppo. Eseguire il codice seguente per risolvere il problema del gruppo di utenti e correggere le autorizzazioni

#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

Nel mio caso è stato causato da un refuso che ho fatto durante la modifica /etc/postgresql/9.5/main/pg_hba.conf

Ho cambiato:

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

per:

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

Ma MD5doveva essere in minuscolo md5:

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

Ho scoperto che disinstallare Postgres non sembra convincente. Questo aiuta a risolvere il mio problema:

1. Avviare il server Postgres:

   sudo systemctl start postgresql
   

2. Assicurarsi che il server si avvii all'avvio:

   sudo systemctl enable postgresql
   

Informazioni dettagliate sono disponibili sul sito DigitalOcean qui.

Non sono riuscito a risolvere questo problema con il mio server postgres-9.5. Dopo 3 giorni di zero progressi provando ogni permutazione di correzione su questo e altri siti, ho deciso di reinstallare il server e perdere 5 giorni di lavoro. Ma ho replicato il problema sulla nuova istanza. Questo potrebbe fornire una prospettiva su come risolverlo prima di adottare l'approccio catastrofico che ho fatto.

Innanzitutto, disabilitare tutte le impostazioni di registrazione in postgresql.conf. Questa è la sezione:

# ERROR REPORTING AND LOGGING

Commenta tutto in quella sezione. Quindi riavviare il servizio.

Al riavvio, utilizzare /etc/init.d/postgresql start o restart ho trovato utile essere in modalità superutente durante il riavvio. Avevo una finestra aperta solo per quell'operazione. È possibile stabilire quella modalità superutente con sudo -i.

Verifica che il server sia raggiungibile con questo semplice comando: psql -l -U postgres

Se ciò non lo risolve, considera questo:

Stavo cambiando la proprietà su molte cartelle mentre cercavo di trovare una soluzione. Sapevo che probabilmente avrei provato a ripristinare quelle proprietà delle cartelle chmodper altri 2 giorni. Se hai già incasinato quelle proprietà delle cartelle e non vuoi eliminare completamente il tuo server, inizia a monitorare le impostazioni di tutte le cartelle interessate per riportarle allo stato originale. Potresti provare a fare un'installazione parallela su un altro sistema e controllare sistematicamente la proprietà e le impostazioni di tutte le cartelle. Tedioso, ma potresti essere in grado di ottenere l'accesso ai tuoi dati.

Una volta ottenuto l'accesso, cambia sistematicamente ogni riga pertinente nella # ERROR REPORTING AND LOGGINGsezione del postgresql.conffile. Riavvia e prova. Ho scoperto che la cartella predefinita per i registri stava causando un errore. Ho espressamente commentato log_directory. La cartella predefinita in cui il sistema rilascia i registri è quindi /var/log/postgresql.

Forse è potuto succedere perché hai cambiato i permessi della /var/lib/postgresql/9.3/maincartella.

Prova a cambiarlo in 700 usando il comando seguente:

sudo chmod 700 main

Questo non è esattamente correlato alla domanda da quando sto usando Flask, ma questo era esattamente l'errore che stavo ottenendo e questo era il filo più rilevante per ottenere idee.

La mia configurazione: sottosistema Windows per Linux, Docker-compose w / makefile w / dockerfile, Flask, Postgresql (utilizzando uno schema costituito da tabelle)

Per connetterti a Postgres, imposta la stringa di connessione in questo modo:

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

NOTA: non ho mai avuto alcun IP (ad esempio localhost, 127.0.0.1) per funzionare usando qualsiasi metodo in questo thread. L'idea di utilizzare il nome del contenitore anziché localhost è nata da qui: https://github.com/docker-library/postgres/issues/297

Imposta il tuo schema:

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

Imposta il percorso di ricerca per le tue funzioni quando imposti la sessione:

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

Ho avuto lo stesso identico problema descritto da Peter Eisentraut. Usando il netstat -nlp | grep 5432comando, ho potuto vedere che il server era in ascolto su socket /tmp/.s.PGSQL.5432.

Per risolvere questo problema, basta modificare il postgresql.conffile e modificare le seguenti righe:

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

Ora esegui service postgresql-9.4 restart(sostituisci 9-4 con la tua versione) e le connessioni remote dovrebbero funzionare ora.

Ora per consentire le connessioni locali, è sufficiente creare un collegamento simbolico alla /var/run/postgresqldirectory.

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

Non dimenticare di assicurarti che anche il tuo pg_hba.confsia configurato correttamente.

Nel mio caso, tutto quello che dovevo fare era questo:

sudo service postgresql restart

e poi

sudo -u postgres psql

Questo ha funzionato bene. Spero che sia d'aiuto. Saluti :) .

Trova il tuo file:

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

Risultato:

/tmp/.s.PGSQL.5432

Accedi come utente postgres:

su postgres
psql -h /tmp/ yourdatabase

Ho avuto lo stesso problema (su Ubuntu 15.10 (astuto)). sudo find / -name 'pg_hba.conf' -printo sudo find / -name 'postgresql.conf' -printgirato vuoto. Prima di allora sembrava che fossero installate più istanze di postgresql.

Potresti avere simili quando vedi come installato o l'elenco dei problemi di dipendenza

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

e così via.

In tal caso, sudo apt-get autoremoveogni pacchetto deve essere 1 per 1.

Quindi seguendo questo alla lettera e starai bene. Soprattutto quando si tratta di importare e aggiungere chiavi all'elenco delle fonti PRIMA

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 -

Se non usi astutamente, sostituiscilo wilycon la tua versione, ovvero con l'output dilsb_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

E poi dovresti stare bene ed essere in grado di connetterti e creare utenti.

Uscita prevista:

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

Fonte delle mie soluzioni (crediti)

Pur avendo lo stesso problema ho provato qualcosa di diverso:

Avvio manuale del demone postgresql ho ottenuto:

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.

Quindi quello che ho fatto è stato fissare un limite inferiore per shared_bufferse max_connectionsin postgresql.confe restartil servizio.

Questo ha risolto il problema!

Ecco il registro degli errori completo:

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

Dopo molti tentativi estenuanti, ho trovato la soluzione basata su altri post!

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

Creare la directory postgresql all'interno di run ed eseguire il comando seguente.

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

Aggiungi semplicemente / tmp unix_socket_directories

postgresql.conf

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