Serwer Postgresql nie uruchamia się

[Ubuntu 16.04] Zainstalowałem postgresql 9.5 wraz z zależnościami:

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

Kiedy chcę uruchomić psql, otrzymuję:

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

Ale /var/run/postgresql/jest pusty. Po ponownym uruchomieniu posgresql wszystko wydaje się w porządku:

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

ale jeśli czek ps auxnie ma takiego PID (dlaczego?)

Całkowita ponowna instalacja wcale nie pomaga. Jak mogę to naprawić?

Jest to charakterystyczne dla systemowej integracji PostgreSQL w Xenial.

Jednostka usługowa postgresql zainstalowana przez pakiet powszechny postgresql jest tylko pozorną usługą, która powoduje, że faktyczna usługa [email protected] jest uruchamiana przez zależność. Zależność tę można zobaczyć, uruchamiając polecenie

systemctl list-dependencies postgresql

Zależność ta nie jest trwała, ale generowana podczas rozruchu systemu przez generator systemowy, /lib/systemd/system-generators/postgresql-generatorktóry jest również dostarczany z pakietem wspólnym postgresql. Generator sprawdza, czy tryb uruchamiania w pliku /etc/postgresql/9.6/main/start.confjest ustawiony auto, a jeśli tak, ustawia zależność, która następnie powoduje uruchomienie instancji 9.6-main.

(Dokładniej, sprawdza wszystkie podkatalogi konfiguracji /etc/postgresql/*/*i tworzy zależności dla wszystkich instancji skonfigurowanych do automatycznego uruchamiania, ale w instalacji domyślnej będzie tylko jedna instancja.)

Z powodu ograniczeń systemowych generatorów (patrz man systemd.generator) proces ten może się nie powieść, powodując brak zależności po ponownym uruchomieniu. Systemd uruchomi wtedy tylko usługę zastępczą , pisząc

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

do dziennika, ale poza tym nic nie robiąc. Próba ręcznego uruchomienia usługi przez

systemctl start postgresql

po prostu odtworzy ten wynik. Uruchamianie polecenia

systemctl daemon-reload

ręcznie jako root uruchomi ponownie generator i w większości przypadków naprawi problem do następnego uruchomienia.

Aby trwale rozwiązać problem, musisz znaleźć przyczynę niepowodzenia generatora podczas uruchamiania. Możliwe przyczyny można znaleźć na stronie systemd.generator. W moim przypadku był to plik konfiguracyjny PostgreSQL, /etc/postgresql/9.6/main/postgresql.confktóry został dowiązany symbolicznie do innego systemu plików, który nie był jeszcze dostępny, gdy generator uruchomił się wcześnie podczas rozruchu. postgresql-generatorsprawdza istnienie tego pliku, nawet jeśli nie jest on potrzebny.

Rozszerzając odpowiedź Tilmana, ale za mało Kudo, aby skomentować ...

Jeśli nie potrzebujesz, aby usługa nazywała się postgresql i nie dbasz o usługę manekina opakowania, powinna działać tylko bezpośrednia kontrola prawdziwej usługi. Jego nazwa to: postgresql@$version-$cluster.service W twoim przypadku powinno to być w skrócie postgresql-9.5-main . Lubię zaczynać

systemctl start [email protected]

i zatrzymać:

systemctl stop [email protected]

Status daje również znacznie lepsze i dokładne informacje niż w przypadku automatycznie generowanej usługi pakowania.

systemctl status [email protected]

W przypadku wersji 9.6 wygląda to tak:

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

W moim przypadku było to związane z nieprawidłowo skonfigurowanymi ustawieniami narodowymi.

Znalazłem rozwiązanie w tej odpowiedzi dba.stackexchange.com :

1. Służy sudo dpkg-reconfigure localesdo generowania niezbędnych ustawień narodowych
2. Usuń istniejący klaster bazy danych przez sudo pg_dropcluster 9.5 main(spowoduje to usunięcie wszystkich danych w klastrze!)
3. Ponownie utwórz klaster za pomocą sudo pg_createcluster 9.5 main --start
4. Uruchom ponownie PostgreSQL przez sudo service postgresql restart

lepiej byłoby użyć systemowych skryptów startowych z Ubuntu 16.04, skrypty init mogą obecnie nie działać poprawnie. Postgres 9.5 znajduje się już w repozytoriach Ubuntu, więc spróbuj, zamiast tego, powinien uruchomić system.

Kolejny „ugryzł to”.

pg_upgradeclusterRzeczywiście opuścił wersji docelowej (9,6) w trybie „Manual” na porcie 5433 i wersji źródłowej (9,5) na porcie 5432.

Nawet po pg_dropcluster 9.5. Edycja pliku start.conf nie pomogła, ale podpowiedź miała zostać użyta systemctl daemon-reload, ponieważ na podstawie tego pliku konfiguracyjnego generator decyduje, czy dowiązać plik usługi:

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

Jeśli więc klaster, który chcesz uruchomić, nie ma słowa „auto” w pliku start.conf, musisz przeładować system (lub uruchomić ponownie), aby włączyć go w czasie uruchamiania.

Nadal muszę to zweryfikować przy ponownym uruchomieniu, ale biorąc pod uwagę powyższe dość pewny, że to był problem.

Wyłączyłem magiczną „super usługę” w ten sposób:

root@server# systemctl disable postgresql

Następnie aktywowałem usługę betonu:

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

Po ponownym uruchomieniu wszystko działało ponownie.

Miałem ten sam błąd, stracone godziny, proste rozwiązanie. Sprawdź to SO pytanie i moją odpowiedź, czyli:

sudo service postgresql restart

Miałem ten problem z innego powodu: uprawnienia do katalogu. Miałem pełny chmod taki jak ten:

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

To powoduje, że katalog nie jest wykonywalny, co uniemożliwia postgresowi jego odczytanie.

Miałem ten sam problem po sprawdzeniu znalezionego problemu z uprawnieniem ssl-cert-snakeoil.key.

Ustaw własność

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

i zrobił czysty restart.