Impossible de se connecter à postgresql sur le port 5432

J'ai installé la pile Bitnami Django qui incluait PostgreSQL 8.4.

Quand je cours, psql -U postgresj'obtiens l'erreur suivante:

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 est définitivement en cours d'exécution et le pg_hba.conffichier ressemble à ceci:

# 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

Ce qui donne?

"Preuve" que pg est en cours d'exécution:

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# 

Ce problème provient de l'installation du postgrespackage sans numéro de version. Bien que postgressera installé et que sa version sera correcte, le script pour configurer le cluster ne fonctionnera pas correctement. c'est un problème d'emballage.

Si vous êtes à l'aise, postgresvous pouvez exécuter un script pour créer ce cluster et le faire postgresfonctionner. Cependant, il existe un moyen plus simple.

Commencez par purger l’ancienne installation postgres. Le problème réside actuellement dans la version 9.1, donc je suppose que c’est ce que vous avez installé.

sudo apt-get remove --purge postgresql-9.1

Maintenant, réinstallez simplement

sudo apt-get install postgresql-9.1

Notez le nom du package avec le numéro de version. HTH.

Le message d'erreur fait référence à un socket de domaine Unix, vous devez donc modifier votre netstatinvocation pour ne pas les exclure. Alors essayez-le sans l'option -t:

netstat -nlp | grep 5432

Je suppose que le serveur écoute réellement sur le socket /tmp/.s.PGSQL.5432plutôt que celui /var/run/postgresql/.s.PGSQL.5432auquel votre client tente de se connecter. Ceci est un problème typique lors de l' utilisation des paquets PostgreSQL main compilé ou tiers sur Debian ou Ubuntu, car la source par défaut pour le répertoire de socket de domaine Unix est /tmpmais l'emballage Debian change à /var/run/postgresql.

Solutions possibles:

• Utilisez les clients fournis par votre forfait tiers (appel /opt/djangostack-1.3-0/postgresql/bin/psql). Désinstallez éventuellement les paquets fournis par Ubuntu (cela pourrait être difficile en raison d'autres dépendances inverses).
• Corrigez le répertoire de socket du paquet tiers pour qu'il soit compatible avec Debian / Ubuntu.
• Utilisez -H localhostplutôt pour vous connecter via TCP / IP.
• Utilisez -h /tmpun PGHOSTparamètre équivalent pour pointer vers le bon répertoire.
• N'utilisez pas de packages tiers.

Cela fonctionne pour moi:

Edit: postgresql.conf

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

Activer ou ajouter:

listen_addresses = '*'

Redémarrez le moteur de base de données:

sudo service postgresql restart

En outre, vous pouvez vérifier le fichier pg_hba.conf

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

Et ajoutez votre adresse réseau ou hôte:

host    all             all             192.168.1.0/24          md5

Vous pouvez utiliser psql -U postgres -h localhostpour forcer la connexion sur TCP plutôt que sur les sockets de domaine UNIX; votre netstatsortie montre que le serveur PostgreSQL écoute sur le port 5432 de localhost.

Vous pouvez savoir quel socket UNIX local est utilisé par le serveur PostgrSQL en utilisant une invocation différente de netstat :

netstat -lp --protocol=unix | grep postgres

Dans tous les cas, les interfaces sur lesquelles le serveur PostgreSQL écoute sont configurées postgresql.conf.

Créez simplement un lien symbolique comme ceci:

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

Je le fais fonctionner en faisant ceci:

dpkg-reconfigure locales

Choisissez vos régions préférées puis exécutez

pg_createcluster 9.5 main --start

(9.5 est ma version de postgresql)

/etc/init.d/postgresql start

et puis ça marche!

sudo su - postgres
psql

J'ai dû compiler PostgreSQL 8.1 sur Debian Squeeze car j'utilise Project Open, basé sur OpenACS et ne fonctionnant pas sur les versions les plus récentes de PostgreSQL.

La configuration de compilation par défaut place l'entrée unix_socketdans /tmp, mais Project Open, qui s'appuie sur PostgreSQL, ne fonctionnerait pas car il rechercherait unix_socketat /var/run/postgresql.

Un paramètre est défini postgresql.confpour définir l'emplacement de la prise. Mon problème était que je pouvais me préparer /tmpet psqltravailler, mais pas pour un projet ouvert, ou je pouvais le faire pour /var/run/postgresqlet psqlne fonctionnerait pas, mais un projet ouvert le faisait.

Une solution au problème consiste à définir le socket pour /var/run/postgresql, puis à l'exécuter psql, en fonction de la suggestion de Peter, comme suit:

psql -h /var/run/postgresql

Ceci s'exécute localement en utilisant les autorisations locales. Le seul inconvénient est qu'il est plus typé que simplement "psql".

L’autre suggestion faite par quelqu'un était de créer un lien symbolique entre les deux lieux. Cela a également fonctionné, mais le lien a disparu au redémarrage. Il est peut-être plus facile d’utiliser simplement l’argument -h. Cependant, j’ai créé le lien symbolique à partir du script PostgreSQL de /etc/init.d. J'ai placé la commande de création de lien symbolique dans la section "démarrer". Bien sûr, lorsque j'émettrai une commande stop and start ou restart, elle essaiera de recréer un lien symbolique existant, mais à part le message d'avertissement, il n'y a probablement aucun mal à cela.

Dans mon cas, au lieu de:

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

j'ai

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

et ont mis explicitement l'unix_socket à /var/run/postgresql/.s.PGSQL.5432en postgresql.conf.

Solution:

Faire ceci

export LC_ALL="en_US.UTF-8"

et ça. ( 9.3 est ma version actuelle de PostgreSQL. Écris ta version!)

sudo pg_createcluster 9.3 main --start

Si votre service Postgres est opérationnel et fonctionne sans erreur ou s'il n'y a pas d'erreur lors du démarrage du service Postgres et que vous obtenez toujours l'erreur mentionnée, procédez comme suit.

Etape 1: Running listera pg_lsclusterstous les clusters postgres en cours d’exécution sur votre appareil.

par exemple:

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

très probablement le statut sera en panne dans votre cas et le service postgres

Étape 2: redémarrez le pg_ctlcluster

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

#restart postgres
sudo service postgres restart

Étape 3: échec de l'étape 2 et erreur renvoyée

Si ce processus n'aboutit pas, une erreur sera générée. Vous pouvez voir le journal des erreurs sur/var/log/postgresql/postgresql-9.6-main.log

Mon erreur était:

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`

Étape 4: vérifier la propriété de postgres

Assurez-vous que postgresc'est le propriétaire de/var/lib/postgresql/version_no/main

Sinon, lancez

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

Étape 5: Vérifiez que l'utilisateur postgres appartient au groupe d'utilisateurs ssl-cert

Il s'est avéré que j'avais supprimé par erreur l'utilisateur Postgres du ssl-certgroupe. Exécutez le code ci-dessous pour résoudre le problème du groupe d'utilisateurs et les autorisations.

#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

Dans mon cas, cela est dû à une faute de frappe que j'ai faite lors de l'édition /etc/postgresql/9.5/main/pg_hba.conf

J'ai changé:

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

à:

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

Mais MD5devait être en minuscule md5:

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

J'ai trouvé que désinstaller Postgres ne semblait pas convaincant. Cela aide à résoudre mon problème:

1. Démarrez le serveur postgres:

   sudo systemctl start postgresql
   

2. Assurez-vous que le serveur démarre au démarrage:

   sudo systemctl enable postgresql
   

Vous trouverez des informations détaillées sur le site DigitalOcean ici.

J'ai échoué à résoudre ce problème avec mon serveur postgres-9.5. Après 3 jours de zéro progrès en essayant chaque permutation de correctif sur ce site et d'autres sites, j'ai décidé de réinstaller le serveur et de perdre 5 jours de travail. Mais, j'ai reproduit le problème sur la nouvelle instance. Cela pourrait donner une idée de la façon de régler le problème avant d'adopter l'approche catastrophique que j'ai adoptée.

Commencez par désactiver tous les paramètres de journalisation dans postgresql.conf. C'est la section:

# ERROR REPORTING AND LOGGING

Commentez tout dans cette section. Puis redémarrez le service.

Lors du redémarrage, utilisez /etc/init.d/postgresql start ou restart j’ai trouvé utile d’être en mode superutilisateur lors du redémarrage. J'avais une x-window ouverte juste pour cette opération. Vous pouvez établir ce mode superutilisateur avecsudo -i .

Vérifiez que le serveur peut être atteint avec cette commande simple: psql -l -U postgres

Si cela ne résout pas le problème, alors considérez ceci:

Je changeais de propriétaire sur plusieurs dossiers en essayant de trouver une solution. Je savais que j'essaierais probablement de rétablir ces propriétaires de dossier et chmods encore 2 jours. Si vous avez déjà manipulé ces dossiers et que vous ne voulez pas purger complètement votre serveur, commencez à suivre les paramètres de tous les dossiers affectés pour les ramener à leur état d'origine. Vous voudrez peut-être essayer de faire une installation parallèle sur un autre système et vérifier systématiquement la propriété et les paramètres de tous les dossiers. Fastidieux, mais vous pourrez peut-être accéder à vos données.

Une fois que vous y avez accès, modifiez systématiquement chaque ligne pertinente dans la # ERROR REPORTING AND LOGGINGsection du postgresql.conffichier. Redémarrez et testez. J'ai constaté que le dossier par défaut des journaux entraînait un échec. J'ai spécifiquement commenté log_directory. Le dossier par défaut dans lequel le système supprime les journaux est alors /var/log/postgresql.

Cela est peut-être dû au fait que vous avez modifié les autorisations du /var/lib/postgresql/9.3/maindossier.

Essayez de le changer en 700 en utilisant la commande ci-dessous:

sudo chmod 700 main

Depuis que j'utilise Flask, ce n'est pas vraiment lié à la question, mais c'était l'erreur exacte que je recevais et c'était le fil le plus pertinent pour obtenir des idées.

Ma configuration: sous-système Windows pour Linux, Docker-composition avec makefile avec dockerfile, Flask, Postgresql (en utilisant un schéma constitué de tableaux)

Pour vous connecter à postgres, configurez votre chaîne de connexion comme suit:

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

REMARQUE: je n'ai jamais obtenu d'adresse IP (par exemple, localhost, 127.0.0.1) pour utiliser une méthode quelconque dans ce fil. L'idée d'utiliser le nom du conteneur au lieu de localhost est venue d'ici: https://github.com/docker-library/postgres/issues/297

Définissez votre schéma:

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

Définissez votre chemin de recherche pour vos fonctions lorsque vous configurez votre session:

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

J'ai eu exactement le même problème que Peter Eisentraut. En utilisant la netstat -nlp | grep 5432commande, je pouvais voir que le serveur écoutait sur socket /tmp/.s.PGSQL.5432.

Pour résoudre ce problème, modifiez simplement votre postgresql.conffichier et modifiez les lignes suivantes:

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

Maintenant, lancez service postgresql-9.4 restart(Remplacez 9-4 par votre version), et les connexions distantes devraient fonctionner maintenant.

Maintenant, pour autoriser les connexions locales, créez simplement un lien symbolique vers le /var/run/postgresqlrépertoire.

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

N'oubliez pas de vous assurer que votre pg_hba.confest correctement configuré aussi.

Dans mon cas, tout ce que je devais faire était ceci:

sudo service postgresql restart

puis

sudo -u postgres psql

Cela a bien fonctionné. J'espère que ça aide. À votre santé :) .

Trouvez votre fichier:

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

Résultat:

/tmp/.s.PGSQL.5432

Connectez-vous en tant qu'utilisateur postgres:

su postgres
psql -h /tmp/ yourdatabase

J'ai eu le même problème (sur Ubuntu 15.10 (astucieux)). sudo find / -name 'pg_hba.conf' -printou sudo find / -name 'postgresql.conf' -printtourné vide. Avant cela, il semblait que plusieurs instances de postgresql avaient été installées.

Vous pouvez avoir le même problème quand vous voyez en tant qu'installé, ou une liste de problèmes de dépendance

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

etc.

Dans ce cas, vous devez sudo apt-get autoremovechaque paquet 1 par 1.

Ensuite, suivez ceci à la lettre et tout ira bien. Surtout quand il s'agit d'importer des clés et de les ajouter à la liste des sources 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 -

Si vous n’utilisez pas wily, remplacez-le wilypar votre version, c’est-à-dire par la sortie delsb_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

Et alors, vous devriez être en mesure de vous connecter et de créer des utilisateurs.

Production attendue:

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

Source de mes solutions (crédits)

Tout en ayant le même problème, j'ai essayé quelque chose de différent:

En démarrant manuellement le démon postgresql, j’ai eu:

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.

Donc , ce que je faisais était de fixer une limite inférieure pour shared_bufferset max_connectionsdans postgresql.confet restartle service.

Cela a résolu le problème!

Voici le journal complet des erreurs:

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

Après de nombreuses tentatives épuisantes, j'ai trouvé la solution à partir d'autres publications!

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

Créez le répertoire postgresql dans run, puis exécutez la commande suivante.

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

Ajoutez simplement / tmp unix_socket_directories

postgresql.conf

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