Il server Postgresql non si avvia

[Ubuntu 16.04] Ho installato postgresql 9.5 insieme alle dipendenze:

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

Quando voglio correre psqlallora ottengo:

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

Ma /var/run/postgresql/è vuoto Quando riavvio posgresql tutto sembra andare bene:

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

ma se controlla ps auxnon c'è tale PID (perché ??)

La reintegrazione totale non aiuta affatto. Come posso ripararlo?

Questa è un'idiosincrasia dell'integrazione systemd di PostgreSQL in Xenial.

L'unità di servizio postgresql installata dal pacchetto postgresql-common è solo un servizio fittizio che provoca l'avvio effettivo del servizio postgresql@9.6-main tramite una dipendenza. Puoi vedere quella dipendenza eseguendo il comando

systemctl list-dependencies postgresql

Tale dipendenza non è permanente, ma generata durante l'avvio del sistema dal generatore di systemd /lib/systemd/system-generators/postgresql-generatorche viene fornito con il pacchetto postgresql-common. Il generatore controlla se la modalità di avvio nel file /etc/postgresql/9.6/main/start.confè impostata su auto, e in tal caso, imposta la dipendenza che provoca successivamente l'avvio dell'istanza 9.6-main.

(Più precisamente, controlla tutte le sottodirectory di configurazione /etc/postgresql/*/*e creerà dipendenze per tutte le istanze configurate per l'avvio automatico, ma in un'installazione predefinita ci sarà solo un'istanza.)

A causa delle limitazioni dei generatori di systemd (consultare man systemd.generator) questo processo potrebbe non riuscire, causando l'assenza delle dipendenze dopo il riavvio. Systemd avvierà quindi solo il servizio fittizio, scrivendo

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

al registro ma per il resto non fare nulla. Tentativo di avviare il servizio manualmente entro

systemctl start postgresql

riprodurrà semplicemente quel risultato. Esecuzione del comando

systemctl daemon-reload

manualmente come root eseguirà nuovamente il generatore e nella maggior parte dei casi risolverà il problema fino al prossimo riavvio.

Per risolvere il problema in modo permanente dovrai trovare il motivo per cui il generatore si guasta durante l'avvio. Le possibili cause sono disponibili nella manpage systemd.generator. Nel mio caso era il file di configurazione PostgreSQL /etc/postgresql/9.6/main/postgresql.confche era collegato a un diverso filesystem che non era ancora disponibile quando il generatore funzionava presto durante l'avvio. postgresql-generatorcontrolla l'esistenza di quel file anche se altrimenti non ne ha bisogno.

Estendendo la risposta di Tilman, ma non abbastanza complimenti per commentare ...

Se non è necessario che il servizio si chiami postgresql e non ci si preoccupi del servizio fittizio wrapper, dovrebbe funzionare solo per controllare direttamente il servizio reale. Il suo nome è: postgresql@$version-$cluster.service Nel tuo caso dovrebbe essere postgresql-9.5-main in breve. Mi piace iniziare

systemctl start postgresql@9.5-main

e per fermare:

systemctl stop postgresql@9.5-main

Lo stato fornisce anche informazioni molto migliori e accurate rispetto al servizio wrapper generato automaticamente.

systemctl status postgresql@9.5-main

Per 9.6 sembra così:

● postgresql@9.6-main.service - PostgreSQL Cluster 9.6-main
   Loaded: loaded (/lib/systemd/system/postgresql@.service; 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/postgresql@9.6-main.service
           ├─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

Nel mio caso questo era correlato a impostazioni locali configurate in modo errato.

Ho trovato la soluzione in questa risposta dba.stackexchange.com :

1. Utilizzare sudo dpkg-reconfigure localesper generare le impostazioni locali necessarie
2. Rilascia il cluster di database esistente tramite sudo pg_dropcluster 9.5 main(questo cancellerà tutti i dati nel cluster!)
3. Ricreare il cluster tramite sudo pg_createcluster 9.5 main --start
4. Riavvia PostgreSQL tramite sudo service postgresql restart

sarebbe meglio usare gli script di avvio di systemd con Ubuntu 16.04, gli script di init potrebbero non funzionare correttamente in questi giorni. Postgres 9.5 è già nei repository di Ubuntu, quindi prova che invece dovrebbe avere l'avvio di systemd.

Un altro "è stato morso da questo".

La pg_upgradeclusterversione di destinazione (9.6) è stata effettivamente lasciata in modalità "manuale" sulla porta 5433 e la versione di origine (9.5) sulla porta 5432.

Anche dopo pg_dropcluster 9.5. La modifica del file start.conf non ha aiutato, ma il suggerimento era di usare systemctl daemon-reload, poiché il generatore decide in base a questo file di configurazione se collegare in modo simbolico il file di servizio:

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

Pertanto, se il cluster che si desidera avviare non ha la parola "auto" in start.conf, è necessario eseguire un ricaricamento del sistema (o riavviare) per averlo abilitato all'avvio.

Devo ancora verificarlo con un riavvio, ma dato quanto sopra abbastanza fiducioso che era il problema.

Ho disabilitato il magico "super servizio" in questo modo:

root@server# systemctl disable postgresql

Quindi ho attivato il servizio concreto:

root@server:~# systemctl enable postgresql@9.5-main.service 

Dopo il riavvio, tutto ha funzionato di nuovo.

Aveva lo stesso errore, ore sprecate, soluzione semplice. Controlla questa domanda SO e la mia risposta, ovvero:

sudo service postgresql restart

Ho avuto questo problema a causa di un motivo diverso: permessi di directory. Ho avuto un chmod completo come questo:

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

Questo imposta la directory come non eseguibile, impedendo a postgres di leggerla.

Ho avuto lo stesso problema dopo aver verificato il problema riscontrato con l'autorizzazione ssl-cert-snakeoil.key.

Imposta proprietà

chown root: ssl-cert ssl-cert-snakeoil.key chmod 640 ssl-cert-snakeoil.key

e ha fatto un riavvio pulito.