Impossibile connettersi a postgresql sulla porta 5432

61

Ho installato lo stack Bitnami Django che includeva PostgreSQL 8.4.

Quando eseguo psql -U postgres ottengo 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 file pg_hba.conf assomiglia a questo:

# 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 è in esecuzione:

[email protected]:/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
[email protected]:/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  
[email protected]:/home/assaf# 
    
posta Assaf Lavie 26.06.2011 - 14:21

18 risposte

69

Questo problema deriva dall'installazione del pacchetto postgres senza un numero di versione. Anche se verrà installato postgres e sarà la versione corretta, lo script per l'installazione del cluster non verrà eseguito correttamente; è un problema di imballaggio.

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

Prima spurga la vecchia installazione di postgres. Il problema si trova attualmente con 9.1 quindi presumo che sia quello che hai installato

sudo apt-get remove --purge postgresql-9.1

Ora semplicemente reinstallare

sudo apt-get install postgresql-9.1

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

    
risposta data Stewart 20.08.2013 - 01:54
19

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

netstat -nlp | grep 5432

Suppongo che il server stia effettivamente ascoltando il socket /tmp/.s.PGSQL.5432 piuttosto che /var/run/postgresql/.s.PGSQL.5432 a cui il tuo 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é l'origine predefinita per la directory socket del dominio Unix è /tmp ma la confezione Debian la modifica in /var/run/postgresql .

Possibili soluzioni alternative:

  • Utilizza i client forniti dal pacchetto di terze parti (chiama /opt/djangostack-1.3-0/postgresql/bin/psql ). Eventualmente disinstallare del tutto i pacchetti forniti da Ubuntu (potrebbe essere difficile a causa di altre dipendenze inverse).
  • Correggere la directory socket del pacchetto di terze parti per essere compatibile con Debian / Ubuntu.
  • Utilizza -H localhost per connettersi tramite TCP / IP.
  • Utilizza -h /tmp o equivalente PGHOST per puntare alla directory giusta.
  • Non utilizzare pacchetti di terze parti.
risposta data Peter Eisentraut 27.06.2011 - 19:41
16

Puoi usare psql -U postgres -h localhost per forzare la connessione a succedere su TCP invece dei socket di dominio UNIX; il tuo output netstat mostra che il server PostgreSQL è in ascolto sulla porta 5432 del localhost.

Puoi scoprire quale socket UNIX locale è usato dal server PostgrSQL usando una diversa invocazione di netstat :

netstat -lp --protocol=unix | grep postgres

In ogni caso, le interfacce su cui il server PostgreSQL è in ascolto sono configurate in postgresql.conf .

    
risposta data Riccardo Murri 26.06.2011 - 14:51
15

Crea semplicemente un collegamento simile a questo:

ln -s /tmp/.s.PGSQL.5432 /var/run/postgresql/.s.PGSQL.5432
    
risposta data Uriel 09.07.2012 - 03:35
13

Questo funziona per me:

Modifica: postgresql.conf

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

Abilita o aggiungi:

listen_addresses = '*'

Riavvia il motore del 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 la tua rete o indirizzo host:

host    all             all             192.168.1.0/24          md5
    
risposta data angelous 09.10.2014 - 15:17
5

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

La configurazione di compilazione predefinita inserisce unix_socket in /tmp , ma Project Open, che si basa su PostgreSQL, non funzionerebbe perché cerca unix_socket a /var/run/postgresql .

C'è un'impostazione in postgresql.conf per impostare la posizione del socket. Il mio problema era che potevo impostare /tmp e psql lavorato, ma non progetto aperto, oppure potrei impostarlo per /var/run/postgresql e psql non funzionerebbe, ma progetto aperto.

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

psql -h /var/run/postgresql

Questo viene eseguito localmente usando le autorizzazioni locali. L'unico inconveniente è che è più una digitazione che semplicemente "psql".

L'altro suggerimento suggerito da qualcuno era di creare un collegamento simbolico tra le due località. Anche questo ha funzionato, ma il collegamento è scomparso al riavvio. Forse è più semplice usare l'argomento -h, tuttavia, ho creato il collegamento simbolico dallo script PostgreSQL in /etc/init.d . Ho inserito il comando di collegamento simbolico nella sezione "start". Naturalmente, quando invio un comando di arresto e avvio o riavvio, tenterà di ricreare un collegamento simbolico esistente, ma a parte il messaggio di avviso, probabilmente non c'è nulla di male.

Nel mio caso, invece di:

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

Ho

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

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

    
risposta data Joe 06.11.2012 - 04:22
5

Lo faccio funzionare in questo modo:

dpkg-reconfigure locales

Scegli le tue impostazioni locali 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
    
risposta data mymusise 13.09.2016 - 11:05
3

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
    
risposta data bogdanvlviv 23.02.2016 - 22:47
2

Nel mio caso è stato causato da un errore di battitura che ho apportato durante la modifica di /etc/postgresql/9.5/main/pg_hba.conf

Ho cambiato:

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

a:

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

Ma MD5 doveva essere in minuscolo md5 :

# Database administrative login by Unix domain socket
local   all             postgres                                md5
    
risposta data Mehdi Nellen 29.11.2016 - 11:15
1

Non sono riuscito a risolvere questo problema con il mio server postgres-9.5. Dopo 3 giorni di progresso zero provando ogni permutazione di correzione su questo e altri siti ho deciso di reinstallare il server e di perdere 5 giorni di lavoro. Ma ho replicato il problema sulla nuova istanza. Ciò potrebbe fornire una certa 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 riavvia il servizio.

Al riavvio, utilizza /etc/init.d/postgresql start o restart Ho trovato utile essere in modalità superutente durante il riavvio. Ho avuto una x-window aperta solo per quell'operazione. Puoi stabilire la modalità di superutente con sudo -i .

Verifica che il server possa essere raggiunto con questo semplice comando: psql -l -U postgres

Se ciò non risolve il problema, considera questo:

Stavo cambiando la proprietà su molte cartelle mentre cercavo di trovare una soluzione. Sapevo che probabilmente avrei tentato di ripristinare le proprietà delle cartelle e chmod s per altri 2 giorni. Se hai già messo in disordine quelle proprietà delle cartelle e non vuoi eliminare completamente il server, inizia a monitorare le impostazioni di tutte le cartelle interessate per riportarle allo stato originale. Potresti provare a eseguire un'installazione parallela su un altro sistema e verificare sistematicamente la proprietà e le impostazioni di tutte le cartelle. Noioso, ma potresti riuscire ad accedere ai tuoi dati.

Una volta ottenuto l'accesso, modifica sistematicamente ciascuna riga pertinente nella sezione # ERROR REPORTING AND LOGGING del file postgresql.conf . Riavvia e prova. Ho trovato che la cartella predefinita per i log stava causando un errore. Ho commentato in modo specifico log_directory . La cartella predefinita in cui il sistema rilascia i registri è quindi /var/log/postgresql .

    
risposta data jurban1997 19.01.2017 - 02:34
1

Se il tuo servizio Postgres è attivo e funzionante senza errori o non ci sono errori nell'avvio del servizio Postgres e continui a ricevere l'errore citato, segui questi passaggi

Passaggio1: l'esecuzione di pg_lsclusters elencherà tutti i cluster Postgres in esecuzione sul dispositivo

es .:

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: Riavvia il pg_ctlcluster

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

#restart postgres
sudo service postgres restart

Passaggio 3: il passaggio 2 non è riuscito e ha generato un errore

Se questo processo non ha successo, verrà generato un errore. Puoi vedere il log degli errori su /var/log/postgresql/postgresql-9.6-main.log

Il mio errore era:

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: controlla la proprietà di postgres

Assicurati che postgres sia il proprietario di /var/lib/postgresql/version_no/main

In caso contrario, esegui

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

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

È risultato che avevo erroneamente rimosso l'utente Postgres dal gruppo ssl-cert . Esegui il codice seguente per risolvere il problema del gruppo utente 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
    
risposta data Noushad PP 16.04.2018 - 16:44
0

Ho avuto lo stesso identico problema descritto da Peter Eisentraut. Utilizzando il comando netstat -nlp | grep 5432 , ho potuto vedere che il server ascoltava sul socket /tmp/.s.PGSQL.5432 .

Per risolvere il problema, modifica il tuo file postgresql.conf e modifica 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 directory /var/run/postgresql .

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

Non dimenticare di assicurarti che anche pg_hba.conf sia configurato correttamente.

    
risposta data Justin Lessard 20.11.2015 - 17:44
0

Nel mio caso, tutto ciò 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 :).

    
risposta data Pranay Dugar 29.06.2017 - 19:21
0

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

  1. Avvia il server postgres:

    sudo systemctl start postgresql
    
  2. Assicurati che il server si avvii all'avvio:

    sudo systemctl enable postgresql
    

Informazioni dettagliate possono essere trovate sul sito DigitalOcean Qui.

    
risposta data parlad neupane 01.02.2018 - 16:45
0

Forse potrebbe essere successo perché hai modificato le autorizzazioni della cartella /var/lib/postgresql/9.3/main .

Prova a cambiarlo in 700 usando il comando seguente:

sudo chmod 700 main
    
risposta data Farzin 06.11.2014 - 14:01
0

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
    
risposta data Waldeyr Mendes da Silva 30.01.2017 - 16:18
0

Ho avuto lo stesso problema (su Ubuntu 15.10 (wily)). sudo find / -name 'pg_hba.conf' -print o sudo find / -name 'postgresql.conf' -print è risultato vuoto. Prima sembrava che fossero installate più istanze di postgresql.

Potresti avere un simile quando vedi installato o problemi con le dipendenze elencando

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

e così via.

In questo caso devi sudo apt-get autoremove ogni pacchetto 1 per 1.

Quindi segui questo alla lettera e starai bene. Soprattutto quando si tratta di importare le chiavi e aggiungere all'elenco di sorgenti 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 -

Se non stai usando wily, sostituisci wily con il tuo rilascio, cioè con l'output di 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

E quindi dovresti stare bene e riuscire a connetterti e creare utenti.

Output previsto:

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)

    
risposta data Grmn 05.02.2016 - 17:43
0

Pur avendo lo stesso problema, ho provato qualcosa di diverso:

Avvio manuale del demone postgresql Ho ricevuto:

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 impostare un limite inferiore per shared_buffers e max_connections in postgresql.conf e restart del servizio.

Questo ha risolto il problema!

Ecco il log 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.
    
risposta data DrFalk3n 26.06.2013 - 15:29

Leggi altre domande sui tag