PostgreSQL nie startuje po instalacji - od czego zacząć diagnozę

PostgreSQL

PostgreSQL nie startuje po instalacji - od czego zacząć diagnozę

W skrócie

Świeżo postawiony PostgreSQL, który nie startuje, potrafi zniechęcić na dzień dobry - a w praktyce sprowadza się to do kilku powtarzalnych przyczyn. Ten problem dotyczy każdego, kto instaluje serwer ręcznie (z paczek dystrybucji albo ze źródeł) i nie korzysta z gotowego, wstępnie skonfigurowanego obrazu. Pokażemy Ci, gdzie naprawdę zapisany jest powód odmowy startu i jak go zdiagnozować w kilka minut, zamiast zgadywać.

Jak to wygląda w praktyce

Najczęściej wygląda to tak - próba startu przez menedżera usług kończy się stanem failed:

$ sudo systemctl start postgresql
$ sudo systemctl status postgresql
* postgresql.service - PostgreSQL RDBMS
     Loaded: loaded (/lib/systemd/system/postgresql.service; enabled)
     Active: failed (Result: exit-code)

Wynik systemctl jest zwykle mało konkretny. Prawdziwy powód znajdziesz dopiero w logu samego serwera, na przykład:

FATAL:  data directory "/var/lib/postgresql/16/main" has invalid permissions
DETAIL:  Permissions should be u=rwx (0700) or u=rwx,g=rx (0750).

To zupełnie inna przyczyna niż zajęty port czy błąd w konfiguracji - a każda daje swój komunikat. Dlatego pierwszy krok to zawsze przeczytanie logu, a nie kolejne próby restartu.

Dlaczego tak się dzieje

PostgreSQL przy starcie sprawdza serię sztywnych warunków. Katalog danych (tzw. data directory, wskazywany przez zmienną PGDATA) musi należeć do użytkownika systemowego postgres i mieć prawa 0700 lub 0750 - inaczej serwer odmawia startu ze względów bezpieczeństwa, bo nie chce udostępnić plików baz osobom trzecim. Port (domyślnie 5432) musi być wolny - jeśli zajmuje go inny, działający już klaster, dostaniesz błąd o niemożliwym otwarciu gniazda. A jeśli w postgresql.conf jest literówka albo parametr z nieprawidłową wartością, serwer przerywa wczytywanie konfiguracji i nie wstaje wcale. Menedżer usług widzi jedynie, że proces zakończył się kodem błędu - szczegół trafia wyłącznie do logu serwera.

Jak to rozwiązać krok po kroku

1. Przeczytaj log serwera - to on ma prawdziwy powód. Na systemd: sudo journalctl -u postgresql -n 50 --no-pager, a plikowy log klastra znajdziesz w katalogu log/ wewnątrz katalogu danych lub w /var/log/postgresql/.
2. Ustal, gdzie jest katalog danych: sudo -u postgres psql -c "SHOW data_directory;" jeśli serwer choć chwilę wstaje, albo sprawdź ścieżkę w pliku usługi i w zmiennej PGDATA.
3. Sprawdź właściciela i prawa katalogu danych: ls -ld /var/lib/postgresql/16/main. Jeśli są złe, napraw: sudo chown -R postgres:postgres /var/lib/postgresql/16/main oraz sudo chmod 700 /var/lib/postgresql/16/main.
4. Sprawdź, czy port 5432 nie jest już zajęty przez inny proces: sudo ss -ltnp | grep 5432. Jeśli jest, albo zatrzymaj drugi klaster, albo zmień parametr port w postgresql.conf.
5. Zweryfikuj konfigurację bez pełnego startu, odpytując pojedynczy parametr: sudo -u postgres /usr/lib/postgresql/16/bin/postgres -D /var/lib/postgresql/16/main -C shared_buffers - błąd składni wskaże problematyczny wpis.
6. Dopiero po usunięciu przyczyny spróbuj ponownie: sudo systemctl start postgresql i od razu sudo systemctl status postgresql.

Jak sprawdzić, że zadziałało

Klaster działa, gdy usługa jest w stanie active (running) i przyjmuje połączenia. Sprawdź to jednym poleceniem serwerowym:

$ pg_isready -h 127.0.0.1 -p 5432
127.0.0.1:5432 - accepting connections

Dla pewności połącz się lokalnie i wypisz wersję - jeśli zapytanie zwróci wynik, serwer w pełni obsługuje ruch:

$ sudo -u postgres psql -c "SELECT version();"

Wróć do listy: 100 najczęstszych pytań i problemów z PostgreSQL

Sprawdź szkolenie: Administracja, replikacja i tuning baz danych PostgreSQL

To szkolenie może być dofinansowane z KFS lub BUR.

★★★★★Średnia ocena naszych szkoleń w Google: 5/5

Sprawdź szkolenie: Zaawansowana administracja PostgreSQL (HA, DR, monitoring, skalowanie)

To szkolenie może być dofinansowane z KFS lub BUR.

★★★★★Średnia ocena naszych szkoleń w Google: 5/5