Não é possível conectar-se ao postgresql na porta 5432

Question

Eu instalei a pilha Bitnami Django que incluía o PostgreSQL 8.4.

Quando executo psql -U postgres , recebo o seguinte erro:

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"?

O PG definitivamente está rodando e o arquivo pg_hba.conf tem esta aparência:

# 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

O que dá?

"Prova" em que a página está em execução:

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# 

    

Answer 1

Esse problema vem da instalação do pacote postgres sem um número de versão. Embora postgres seja instalado e seja a versão correta, o script para configurar o cluster não será executado corretamente; é um problema de embalagem.

Se você estiver satisfeito com postgres , há um script que pode ser executado para criar este cluster e obter postgres em execução. No entanto, há um caminho mais fácil.

Primeiro, purgar a instalação antiga do postgres. A questão atualmente está com 9.1, então vou assumir que é isso que você instalou

sudo apt-get remove --purge postgresql-9.1

Agora simplesmente reinstale

sudo apt-get install postgresql-9.1

Anote o nome do pacote com o número da versão. HTH.

    

Answer 2

A mensagem de erro refere-se a um soquete do domínio Unix, portanto, você precisa ajustar sua invocação netstat para não excluí-los. Então tente sem a opção -t :

netstat -nlp | grep 5432

Eu acho que o servidor está realmente ouvindo no soquete /tmp/.s.PGSQL.5432 em vez do /var/run/postgresql/.s.PGSQL.5432 que o seu cliente está tentando conectar. Este é um problema típico ao usar pacotes PostgreSQL compilados manualmente ou de terceiros no Debian ou Ubuntu, porque o padrão de origem para o diretório de soquete do domínio Unix é /tmp , mas o pacote Debian o altera para /var/run/postgresql .

Soluções possíveis:

• Use os clientes fornecidos pelo pacote de terceiros (chamada /opt/djangostack-1.3-0/postgresql/bin/psql ). Possivelmente, desinstalar completamente os pacotes fornecidos pelo Ubuntu (pode ser difícil por causa de outras dependências reversas).
• Corrija o diretório de soquete do pacote de terceiros para ser compatível com o Debian / Ubuntu.
• Use -H localhost para se conectar via TCP / IP.
• Use a configuração -h /tmp ou equivalente PGHOST para apontar para o diretório correto.
• Não use pacotes de terceiros.

Answer 3

Você pode usar psql -U postgres -h localhost para forçar a conexão a ocorrer por TCP em vez de soquetes de domínio UNIX; sua saída netstat mostra que o servidor PostgreSQL está escutando na porta 5432 do localhost.

Você pode descobrir qual socket UNIX local é usado pelo servidor PostgrSQL usando uma invocavação diferente de netstat :

netstat -lp --protocol=unix | grep postgres

De qualquer forma, as interfaces nas quais o servidor PostgreSQL atende estão configuradas em postgresql.conf .

    

Answer 4

Basta criar um link como este:

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

    

Answer 5

Isso funciona para mim:

Edite: postgresql.conf

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

Ativar ou adicionar:

listen_addresses = '*'

Reinicie o mecanismo do banco de dados:

sudo service postgresql restart

Além disso, você pode verificar o arquivo pg_hba.conf

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

Adicione sua rede ou endereço de host:

host    all             all             192.168.1.0/24          md5

    

Answer 6

Eu tive que compilar o PostgreSQL 8.1 no Debian Squeeze porque estou usando o Project Open, que é baseado no OpenACS e não será executado em versões mais recentes do PostgreSQL.

A configuração de compilação padrão coloca o unix_socket em /tmp , mas o Project Open, que depende do PostgreSQL, não funcionará porque ele procura o unix_socket at /var/run/postgresql .

Há uma configuração em postgresql.conf para definir o local do soquete. Meu problema era que eu poderia definir para /tmp e psql trabalhado, mas não para o projeto aberto, ou poderia configurá-lo para /var/run/postgresql e psql não funcionaria, mas o projeto aberto funcionava.

Uma solução para o problema é definir o soquete para /var/run/postgresql e, em seguida, executar psql , com base na sugestão de Peter, como:

psql -h /var/run/postgresql

Isso é executado localmente usando permissões locais. A única desvantagem é que é mais digitação do que simplesmente "psql".

A outra sugestão que alguém fez foi criar um link simbólico entre os dois locais. Isso também funcionou, mas o link desapareceu após a reinicialização. Talvez seja mais fácil usar apenas o argumento -h, no entanto, criei o link simbólico a partir do script do PostgreSQL em /etc/init.d . Coloquei o comando symbolic link create na seção "start". É claro que, quando eu emita um comando para parar e iniciar ou reiniciar, ele tentará recriar um link simbólico existente, mas, além da mensagem de aviso, provavelmente não haverá danos nisso.

No meu caso, em vez de:

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

Eu tenho

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

e definiram explicitamente o unix_socket como /var/run/postgresql/.s.PGSQL.5432 in postgresql.conf .

    

Answer 7

Eu faço funcionar fazendo isso:

dpkg-reconfigure locales

Escolha suas localidades preferidas e, em seguida, execute

pg_createcluster 9.5 main --start

(9,5 é a minha versão do postgresql)

/etc/init.d/postgresql start

e depois funciona!

sudo su - postgres
psql

    

Answer 8

Solução:

Faça isso

export LC_ALL="en_US.UTF-8"

e isso. ( 9.3 é a minha versão atual do PostgreSQL. Escreva sua versão!)

sudo pg_createcluster 9.3 main --start

    

Answer 9

No meu caso, isso foi causado por um erro de digitação que eu cometi ao editar /etc/postgresql/9.5/main/pg_hba.conf

eu mudei:

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

para:

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

Mas MD5 tinha que ser minúscula md5 :

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

    

Answer 10

Não consegui resolver este problema com o meu servidor postgres-9.5. Após 3 dias de zero progresso tentando cada permutação de correção neste e em outros sites, decidi reinstalar o servidor e perder 5 dias de trabalho. Mas eu repliquei o problema na nova instância. Isso pode fornecer alguma perspectiva sobre como corrigi-lo antes de você adotar a abordagem catastrófica que fiz.

Primeiro, desative todas as configurações de log no postgresql.conf. Esta é a seção:

# ERROR REPORTING AND LOGGING

Comente tudo nessa seção. Em seguida, reinicie o serviço.

Ao reiniciar, use /etc/init.d/postgresql start ou restart Eu achei útil estar no modo de superusuário durante a reinicialização. Eu tinha uma janela x aberta apenas para essa operação. Você pode estabelecer esse modo de superusuário com sudo -i .

Verifique se o servidor pode ser alcançado com este comando simples: psql -l -U postgres

Se isso não resolver, considere isso:

Eu estava mudando a propriedade em muitas pastas ao tentar encontrar uma solução. Eu sabia que provavelmente estaria tentando reverter essas posses de pasta e chmod s por mais dois dias. Se você já tiver mexido com essas propriedades de pasta e não quiser limpar completamente o servidor, comece a acompanhar as configurações de todas as pastas afetadas para recuperá-las para o estado original. Você pode querer tentar fazer uma instalação paralela em outro sistema e verificar sistematicamente a propriedade e as configurações de todas as pastas. Tédio, mas você pode conseguir acessar seus dados.

Depois de obter acesso, altere sistematicamente cada linha relevante na seção # ERROR REPORTING AND LOGGING do arquivo postgresql.conf . Reinicie e teste. Eu achei que a pasta padrão para os logs estava causando uma falha. Eu comentei especificamente log_directory . A pasta padrão na qual o sistema coloca os logs é, então, /var/log/postgresql .

    

Answer 11

Eu tive exatamente o mesmo problema que Peter Eisentraut descreveu. Usando o comando netstat -nlp | grep 5432 , pude ver que o servidor estava escutando no soquete /tmp/.s.PGSQL.5432 .

Para corrigir isso, basta editar seu arquivo postgresql.conf e alterar as seguintes linhas:

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

Agora execute service postgresql-9.4 restart (substitua 9-4 pela sua versão) e as conexões remotas devem estar funcionando agora.

Agora, para permitir conexões locais, basta criar um link simbólico para o diretório /var/run/postgresql .

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

Não se esqueça de verificar se o pg_hba.conf está configurado corretamente também.

    

Answer 12

No meu caso, tudo o que eu tinha que fazer era isso:

sudo service postgresql restart

e depois

sudo -u postgres psql

Isso funcionou muito bem. Espero que ajude. Felicidades :).

    

Answer 13

Eu descobri que desinstalar o Postgres não parece convincente. Isso ajuda a resolver meu problema:

1. Inicie o servidor postgres:

   sudo systemctl start postgresql
   

2. Verifique se o servidor inicia na inicialização:

   sudo systemctl enable postgresql
   

Informações detalhadas podem ser encontradas no site da DigitalOcean Aqui.

    

Answer 14

Possivelmente isso poderia ter acontecido porque você alterou as permissões da pasta /var/lib/postgresql/9.3/main .

Tente alterá-lo para 700 usando o comando abaixo:

sudo chmod 700 main

    

Answer 15

Encontre o seu arquivo:

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

Resultado:

/tmp/.s.PGSQL.5432

Login como usuário postgres:

su postgres
psql -h /tmp/ yourdatabase

    

Answer 16

Eu tive o mesmo problema (no Ubuntu 15.10 (astuto)). sudo find / -name 'pg_hba.conf' -print ou sudo find / -name 'postgresql.conf' -print ficou vazio. Antes disso, parecia que várias instâncias do postgresql foram instaladas.

Você pode ter algo semelhante quando estiver instalado ou listando problemas de dependência

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

e assim por diante.

Nesse caso, você deve sudo apt-get autoremove de cada pacote 1 por 1.

Depois disso, siga a carta e você ficará bem. Especialmente quando se trata de importar e adicionar à lista de fontes 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 não estiver usando o astuto, substitua wily pela sua versão, ou seja, com a saída de 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 então você deve estar bem e ser capaz de se conectar e criar usuários.

Resultado esperado:

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 das minhas soluções (créditos)

    

Answer 17

Se o seu serviço Postgres estiver ativo e em execução sem qualquer erro ou não houver erro ao iniciar o serviço Postgres e você ainda estiver recebendo o erro mencionado, siga estas etapas

Etapa 1: a execução de pg_lsclusters listará todos os clusters de postgres em execução no seu dispositivo

por exemplo:

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

provavelmente o status será baixo no seu caso e no serviço postgres

Passo 2: Reinicie o pg_ctlcluster

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

#restart postgres
sudo service postgres restart

Etapa 3: a etapa 2 falhou e jogou erro

Se esse processo não for bem-sucedido, ocorrerá um erro. Você pode ver o log de erros em /var/log/postgresql/postgresql-9.6-main.log

Meu erro foi:

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'

Etapa 4: verifique a propriedade dos postgres

Certifique-se de que postgres seja o proprietário de /var/lib/postgresql/version_no/main

Se não, corra

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

Etapa 5: Verificar se o usuário postgres pertence ao grupo de usuários ssl-cert

Descobri que eu havia removido erroneamente o usuário do Postgres do grupo ssl-cert . Execute o código abaixo para corrigir o problema do grupo de usuários e corrija as permissões

#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

    

Answer 18

Apesar de ter o mesmo problema, tentei algo diferente:

Iniciando manualmente o daemon postgresql, obtive:

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.

O que fiz foi definir um limite inferior para shared_buffers e max_connections em postgresql.conf e restart do serviço.

Isso resolveu o problema!

Este é o log de erros 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.