Impossible de se connecter à postgresql sur le port 5432

Question

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

Lorsque j'exécute psql -U postgres j'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 en cours d'exécution et le fichier pg_hba.conf se présente comme suit:

# 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#

Stewart · Answer

Ce problème provient de l'installation du package postgres sans numéro de version. Bien que postgres soit installé et que sa version soit correcte, le script permettant d’installer le cluster ne fonctionnera pas correctement; c'est un problème d'emballage.

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

Commencez par purger l’ancien 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.

Peter Eisentraut · Answer

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

netstat -nlp | grep 5432

Je suppose que le serveur écoute en fait le socket /tmp/.s.PGSQL.5432 plutôt que le /var/run/postgresql/.s.PGSQL.5432 auquel votre client tente de se connecter. C'est un problème typique lors de l'utilisation de packages PostgreSQL tiers ou compilés à la main sur Debian ou Ubuntu, car le répertoire source du répertoire de socket du domaine Unix est par défaut /tmp mais le package Debian le modifie en /var/run/postgresql.

Solutions possibles:

Utilisez les clients fournis par votre package tiers (appelez /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 localhost pour vous connecter via TCP/IP à la place.
Utilisez -h /tmp ou l'équivalent PGHOST pour pointer vers le bon répertoire.
N'utilisez pas de packages tiers.

Riccardo Murri · Answer

Vous pouvez utiliser psql -U postgres -h localhost pour forcer la connexion sur TCP au lieu des sockets de domaine UNIX; votre sortie netstat indique 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

Quoi qu'il en soit, les interfaces sur lesquelles le serveur PostgreSQL écoute sont configurées dans postgresql.conf.

angelous · Answer

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

Uriel · Answer

Créez simplement un lien symbolique comme ceci:

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

mymusise · Answer

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

Joe · Answer

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 le unix_socket dans /tmp, mais Project Open, qui repose sur PostgreSQL, ne fonctionnerait pas car il cherchait le unix_socket à /var/run/postgresql.

postgresql.conf permet de définir l'emplacement de la socket. Mon problème était que je pouvais soit définir pour /tmp et psql, mais pas ouvrir le projet, ou je pouvais le définir pour /var/run/postgresql et psql ne fonctionnerait pas, mais le projet ouvert le faisait.

Une solution au problème consiste à définir le socket pour /var/run/postgresql, puis à 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 dans /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 pas de 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 explicitement défini le unix_socket sur /var/run/postgresql/.s.PGSQL.5432 dans postgresql.conf.

Noushad · Answer

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.

Étape 1: Exécuter `pg_lsclusters` listera tous 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 postgres 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 groupe ssl-cert. 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

bogdanvlviv · Answer

Solution:

Faire ceci

export LC_ALL="en_US.UTF-8"

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

Sudo pg_createcluster 9.3 main --start

jurban1997 · Answer

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 un aperçu 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. Il m'a été utile de rester en mode superutilisateur lors du redémarrage. J'avais une x-window ouverte juste pour cette opération. Vous pouvez établir ce mode superutilisateur avec Sudo -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 dossiers et chmods pendant 2 jours supplémentaires. 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 impacté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 avez obtenu l'accès, modifiez systématiquement chaque ligne pertinente dans la section # ERROR REPORTING AND LOGGING du fichier postgresql.conf. 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.

Mehdi Nellen · Answer

Dans mon cas, cela est dû à une faute de frappe que j'ai faite en éditant /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 MD5 devait être en minuscule md5:

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

Josh Graham · Answer

Cela n’a rien à voir avec la question puisque j’utilise Flask, mais c’est l’erreur exacte que j’entendais et c’est le fil le plus pertinent pour obtenir des idées.

Ma configuration: sous-système Windows pour Linux, composition Docker avec makefile avec fichier docker, Flask, Postgresql (à l'aide d'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 eu aucune adresse IP (par exemple, localhost, 127.0.0.1) pour travailler en utilisant une méthode 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>")

parlad neupane · Answer

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

Démarrez le serveur postgres:
```
Sudo systemctl start postgresql 
```
Assurez-vous que le serveur démarre au démarrage:
```
Sudo systemctl enable postgresql 
```

Des informations détaillées sont disponibles sur le site DigitalOcean Here.

Farzin · Answer

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

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

Sudo chmod 700 main

Justin Lessard · Answer

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

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

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

Exécutez maintenant 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 répertoire /var/run/postgresql.

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

N'oubliez pas de vous assurer que votre pg_hba.conf est également correctement configuré.

Pradeep Maurya · Answer

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

Pranay Dugar · Answer

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

Sudo service postgresql restart

et alors

Sudo -u postgres psql

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

Douglas Rosa · Answer

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

DrFalk3n · Answer

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.

J'ai donc défini une limite inférieure pour shared_buffers et max_connections dans postgresql.conf et restart du 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.

Blue · Answer

Ajoutez simplement/tmp unix_socket_directories

postgresql.conf

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

Waldeyr Mendes da Silva · Answer

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

Grmn · Answer

J'ai eu le même problème (sur Ubuntu 15.10 (astucieux)). Sudo find / -name 'pg_hba.conf' -print ou Sudo find / -name 'postgresql.conf' -print est arrivé 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 autoremove chaque 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 wily par votre version, c’est-à-dire par le résultat 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

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)