El servidor Postgresql no se inicia

[Ubuntu 16.04] instalé postgresql 9.5 junto con las dependencias:

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

Cuando quiero correr psqlme sale:

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

Pero /var/run/postgresql/esta vacio. Cuando reinicio posgresql todo parece estar bien:

$ /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)

pero si marca ps auxno hay tal PID (¿por qué?)

La reinstalación total no ayuda en absoluto. ¿Cómo puedo arreglarlo?

Esta es una idiosincrasia de la integración systemd de PostgreSQL en Xenial.

La unidad de servicio postgresql instalada por el paquete postgresql-common es solo un servicio ficticio que hace que el servicio real [email protected] se inicie a través de una dependencia. Puede ver esa dependencia ejecutando el comando

systemctl list-dependencies postgresql

Esa dependencia no es permanente, sino que se genera durante el arranque del sistema por el generador systemd /lib/systemd/system-generators/postgresql-generatorque también viene con el paquete postgresql-common. El generador verifica si el modo de inicio en el archivo /etc/postgresql/9.6/main/start.confestá configurado y auto, de ser así, configura la dependencia que posteriormente hace que se inicie la instancia 9.6-main.

(Más precisamente, verifica todos los subdirectorios de configuración /etc/postgresql/*/*y creará dependencias para todas las instancias que están configuradas para el inicio automático, pero en una instalación predeterminada solo habrá una instancia).

Debido a las limitaciones de los generadores de systemd (ver man systemd.generator), este proceso puede fallar, causando que las dependencias estén ausentes después de un reinicio. Systemd iniciará solo el servicio ficticio, escribiendo

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

al registro pero de lo contrario no hacer nada. Intentando iniciar el servicio manualmente

systemctl start postgresql

solo reproducirá ese resultado. Ejecutando el comando

systemctl daemon-reload

manualmente como root volverá a ejecutar el generador y, en la mayoría de los casos, solucionará el problema hasta el próximo reinicio.

Para resolver el problema de forma permanente, tendrá que encontrar la razón por la cual el generador falla durante el arranque. Las causas posibles se pueden encontrar en la página de manual systemd.generator. En mi caso, fue el archivo de configuración de PostgreSQL /etc/postgresql/9.6/main/postgresql.confque estaba vinculado a un sistema de archivos diferente que aún no estaba disponible cuando el generador se ejecutó temprano durante el arranque. postgresql-generatorcomprueba la existencia de ese archivo aunque no lo necesite de otra manera.

Extendiendo la respuesta de Tilman, pero no lo suficiente Kudos para comentar ...

Si no necesita que el servicio se llame postgresql y no le importa el servicio ficticio del contenedor, debería funcionar solo para controlar el servicio real directamente. Su nombre es: postgresql@$version-$cluster.service En su caso, debe ser postgresql-9.5-main en resumen. Me gusta empezar

systemctl start [email protected]

y para parar:

systemctl stop [email protected]

El estado también le dará información mucho mejor y más precisa que en el servicio de envoltorio generado automáticamente.

systemctl status [email protected]

Para 9.6 se ve así:

● [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

En mi caso, esto estaba relacionado con configuraciones regionales configuradas incorrectamente.

He encontrado la solución en esta respuesta de dba.stackexchange.com :

1. Use sudo dpkg-reconfigure localespara generar las configuraciones regionales necesarias
2. Elimine el clúster de base de datos existente sudo pg_dropcluster 9.5 main(¡esto borrará todos los datos en el clúster!
3. Vuelva a crear el clúster a través de sudo pg_createcluster 9.5 main --start
4. Reinicie PostgreSQL a través de sudo service postgresql restart

sería mejor usar scripts de inicio systemd con ubuntu 16.04, los scripts de inicio podrían no funcionar correctamente en estos días. Postgres 9.5 ya está en los repositorios de ubuntu, así que intente eso, debería tener inicio de systemd.

Otro "fue mordido por esto".

En pg_upgradeclusterrealidad, dejó la versión de destino (9.6) en modo "manual" en el puerto 5433 y la versión de origen (9.5) en el puerto 5432.

Incluso despues pg_dropcluster 9.5. La edición del archivo start.conf no ayudó, pero la sugerencia era usar systemctl daemon-reload, ya que el generador decide en base a este archivo de configuración si vincular el archivo de servicio:

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

Por lo tanto, si el clúster que desea iniciar no tiene la palabra "auto" en start.conf, debe hacer una recarga del sistema (o reiniciar) para habilitarlo en el momento del arranque.

Todavía tengo que verificar esto con un reinicio, pero dado lo anterior estoy bastante seguro de que ese era el problema.

Deshabilité el "super servicio" mágico así:

root@server# systemctl disable postgresql

Entonces activé el servicio concreto:

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

Después de reiniciar todo funcionó nuevamente.

Tenía el mismo error, horas perdidas, solución simple. Marque esta pregunta SO y mi respuesta, que es:

sudo service postgresql restart

Tuve este problema debido a una razón diferente: permisos de directorio. Tuve un chmod de barrido completo como este:

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

Esto establece el directorio como no ejecutable, lo que evita que postgres lo lea.

Tuve este mismo problema al verificar el problema encontrado con el permiso ssl-cert-snakeoil.key.

Establecer propiedad

raíz conocida: ssl-cert ssl-cert-snakeoil.key chmod 640 ssl-cert-snakeoil.key

e hizo un reinicio limpio.