Le serveur PostgreSQL ne démarre pas

[Ubuntu 16.04] J'ai installé postgresql 9.5 avec les dépendances:

sudo sh -c "echo 'deb http://apt.postgresql.org/pub/repos/apt/ xenial-pgdg main' > /etc/apt/sources.list.d/pgdg.list"
wget --quiet -O - http://apt.postgresql.org/pub/repos/apt/ACCC4CF8.asc | sudo apt-key add -
sudo apt-get update
sudo apt-get install postgresql-common
sudo apt-get install postgresql-9.5 libpq-dev

Quand je veux courir, psqlje reçois:

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

Mais /var/run/postgresql/est vide. Lorsque je redémarre posgresql, tout semble bien se passer:

$ /etc/init.d/postgresql restart
[ ok ] Restarting postgresql (via systemctl): postgresql.service.

$ /etc/init.d/postgresql status
● postgresql.service - PostgreSQL RDBMS
   Loaded: loaded (/lib/systemd/system/postgresql.service; enabled; vendor preset: enabled)
   Active: active (exited) since wto 2016-09-27 16:18:26 CEST; 1min 15s ago
  Process: 3076 ExecReload=/bin/true (code=exited, status=0/SUCCESS)
  Process: 3523 ExecStart=/bin/true (code=exited, status=0/SUCCESS)
 Main PID: 3523 (code=exited, status=0/SUCCESS)

mais si vérifier ps auxil n'y a pas un tel PID (pourquoi ??)

La réintégration totale n'aide pas du tout. Comment puis-je le réparer?

C'est une idiosyncrasie de l'intégration systemd de PostgreSQL dans Xenial.

L'unité de service postgresql installée par le package postgresql-common n'est qu'un service factice qui provoque le démarrage du service réel [email protected] via une dépendance. Vous pouvez voir cette dépendance en exécutant la commande

systemctl list-dependencies postgresql

Cette dépendance n'est pas permanente, mais générée lors du démarrage du système par le générateur systemd /lib/systemd/system-generators/postgresql-generatorqui est également fourni avec le package postgresql-common. Le générateur vérifie si le mode de démarrage dans le fichier /etc/postgresql/9.6/main/start.confest défini sur auto, et si c'est le cas, configure la dépendance qui entraîne ensuite le démarrage de l'instance 9.6-main.

(Plus précisément, il vérifie tous les sous /etc/postgresql/*/*- répertoires de configuration et créera des dépendances pour toutes les instances configurées pour le démarrage automatique, mais dans une installation par défaut, il n'y aura qu'une seule instance.)

En raison des limitations des générateurs systemd (voir man systemd.generator), ce processus peut échouer, entraînant l'absence des dépendances après un redémarrage. Systemd démarrera alors uniquement le service factice, en écrivant

systemd[1]: Starting PostgreSQL RDBMS...
systemd[1]: Started PostgreSQL RDBMS.

dans le journal, mais sinon ne rien faire. Tentative de démarrage du service manuellement par

systemctl start postgresql

va juste reproduire ce résultat. Exécuter la commande

systemctl daemon-reload

manuellement en tant que root réexécutera le générateur et dans la plupart des cas, résoudra le problème jusqu'au prochain redémarrage.

Pour résoudre définitivement le problème, vous devrez trouver la raison pour laquelle le générateur tombe en panne au démarrage. Les causes possibles peuvent être trouvées dans la page de manuel systemd.generator. Dans mon cas, c'était le fichier de configuration PostgreSQL /etc/postgresql/9.6/main/postgresql.confqui était lié à un autre système de fichiers qui n'était pas encore disponible lorsque le générateur s'est exécuté tôt pendant le démarrage. postgresql-generatorvérifie l'existence de ce fichier même s'il n'en a pas besoin autrement.

S'étendant sur la réponse de Tilman, mais pas assez de félicitations pour commenter ...

Si vous n'avez pas besoin que le service soit appelé postgresql et que vous ne vous souciez pas du service factice de wrapper, il devrait fonctionner pour contrôler directement le service réel. Son nom est: postgresql@$version-$cluster.service Dans votre cas, ce devrait être postgresql-9.5-main en bref. Comme pour commencer

systemctl start [email protected]

et pour arrêter:

systemctl stop [email protected]

Le statut vous donnera également des informations bien meilleures et précises que sur le service d'emballage généré automatiquement.

systemctl status [email protected]

Pour 9.6, cela ressemble à ceci:

● [email protected] - PostgreSQL Cluster 9.6-main
   Loaded: loaded (/lib/systemd/system/[email protected]; disabled; vendor preset: enabled)
   Active: active (running) since Wed 2017-09-13 00:41:50 CEST; 7h ago
  Process: 10235 ExecStop=/usr/bin/pg_ctlcluster --skip-systemctl-redirect -m fast %i stop (code=exited, status=2)
  Process: 10676 ExecStart=postgresql@%i --skip-systemctl-redirect %i start (code=exited, status=0/SUCCESS)
 Main PID: 10683 (postgres)
   CGroup: /system.slice/system-postgresql.slice/[email protected]
           ├─10683 /usr/lib/postgresql/9.6/bin/postgres -D /var/lib/postgresql/9.6/main -c config_file=/etc/postgresql/9.6/main/postgresql.conf
           ├─10685 postgres: 9.6/main: checkpointer process
           ├─10686 postgres: 9.6/main: writer process
           ├─10748 postgres: 9.6/main: wal writer process
           ├─10749 postgres: 9.6/main: autovacuum launcher process
           ├─10750 postgres: 9.6/main: archiver process   last was 000000020000000000000082
           ├─10751 postgres: 9.6/main: stats collector process

Dans mon cas, cela était lié à des paramètres régionaux mal configurés.

J'ai trouvé la solution dans cette réponse dba.stackexchange.com :

1. Utilisez sudo dpkg-reconfigure localespour générer les paramètres régionaux nécessaires
2. Supprimez le cluster de base de données existant via sudo pg_dropcluster 9.5 main(cela effacera toutes les données du cluster!)
3. Recréer le cluster via sudo pg_createcluster 9.5 main --start
4. Redémarrez PostgreSQL via sudo service postgresql restart

il serait préférable d'utiliser les scripts de démarrage de systemd avec ubuntu 16.04, les scripts init peuvent ne pas fonctionner correctement de nos jours. Postgres 9.5 est déjà dans le référentiel ubuntu, alors essayez plutôt de démarrer systemd.

Un autre "s'est fait mordre par ça".

Le pg_upgradeclusterfait a laissé la version cible (9.6) en mode "manuel" sur le port 5433 et la version source (9.5) sur le port 5432.

Même après pg_dropcluster 9.5. La modification du fichier start.conf n'a pas aidé, mais le conseil était à utiliser systemctl daemon-reload, car le générateur décide en fonction de ce fichier de configuration de lier ou non le fichier de service:

for conf in /etc/postgresql/*/*/postgresql.conf; do
    # trimmed for brevity
    [ "$start" = "auto" ] || continue
    ln -s "$pgservice" "$wantdir/postgresql@$version-$cluster.service"
done

Donc, si le cluster que vous souhaitez démarrer ne contient pas le mot "auto" dans start.conf, vous devez effectuer un rechargement du système (ou un redémarrage) pour l'activer au démarrage.

Je dois encore vérifier cela avec un redémarrage, mais étant donné ce qui précède, je pense que c'était le problème.

J'ai désactivé le "super service" magique comme ceci:

root@server# systemctl disable postgresql

J'ai ensuite activé le service concret:

root@server:~# systemctl enable [email protected] 

Après le redémarrage, tout a de nouveau fonctionné.

Eu la même erreur, des heures perdues, une solution simple. Vérifiez cette question SO et ma réponse, qui est:

sudo service postgresql restart

J'ai eu ce problème pour une autre raison: les autorisations de répertoire. J'ai eu un chmod à balayage complet comme celui-ci:

chmod -R 644 /etc/postgresql/10/main

Cela définit le répertoire comme non exécutable, ce qui empêche les postgres de le lire.

J'ai eu ce même problème lors de la vérification du problème trouvé avec l'autorisation ssl-cert-snakeoil.key.

Définir la propriété

racine de chown: ssl-cert ssl-cert-snakeoil.key chmod 640 ssl-cert-snakeoil.key

et a fait un redémarrage propre.