„FATAL: plik blokady” postmaster.pid „już istnieje”


68

Właśnie przeinstalowałem postgres przez brew install postgres

Pobiegłem, initdb /usr/local/var/postgres -E utf8ale dostałem to:

The files belonging to this database system will be owned by user "atal421".
This user must also own the server process.

The database cluster will be initialized with locale "en_US.UTF-8".
The default text search configuration will be set to "english".

initdb: directory "/usr/local/var/postgres" exists but is not empty
If you want to create a new database system, either remove or empty
the directory "/usr/local/var/postgres" or run initdb
with an argument other than "/usr/local/var/postgres".

więc mam rm -rffolder postgres i uruchomiłem go ponownie:

 initdb /usr/local/var/postgres -E utf8

powiedziało, że wszystko jest w porządku:

Success. You can now start the database server using:

    postgres -D /usr/local/var/postgres

więc uruchomiłem to polecenie i otrzymałem:

postgres -D /usr/local/var/postgres


FATAL:  lock file "postmaster.pid" already exists
HINT:  Is another postmaster (PID 13731) running in data directory "/usr/local/var/postgres"?

Teraz, gdy patrzę na monitor aktywności, widzę 6 wystąpień adresu pocztowego.

Jak to naprawić?


Prawdopodobnie widzisz jedno wystąpienie postgresz postmasterem i pięcioma backendami narzędziowymi. PostgreSQL to architektura wieloprocesowa.
Craig Ringer

Odpowiedzi:


104

Ogłoszenie o usługach publicznych: nigdy nie usuwaj postmaster.pid. Naprawdę. Świetny sposób na uszkodzenie danych.

Masz już zainstalowany PostgreSQL i usunąłeś katalog danych bez zatrzymywania działającego serwera. Masz teraz niektóre osierocone procesy serwera PostgreSQL, które zarządzają usuniętymi plikami danych, więc nie są one już dostępne w systemie plików i zostaną całkowicie usunięte, gdy ostatni otwarty uchwyt pliku zostanie zamknięty. Nie można użyć pg_ctldo zamknięcia serwera w normalny sposób, ponieważ usunąłeś katalog danych klastra, więc musisz po prostu zabić procesy. Zabij postmastera ( nie używaj kill -9, wystarczy zwykłe zabójstwo), a reszta też się wyłączy.

Będziesz wtedy mógł uruchomić nowy serwer w katalogu danych w oparciu o świeżo initdbzapisane dane.

Jest wysoce prawdopodobne, że wystąpią konflikty na późniejszym etapie, chyba że odinstalujesz inną starszą wersję PostgreSQL.

W skrócie:

cat /usr/local/var/postgres/postmaster.pid

Zanotuj numer w pierwszym wierszu, który jest pid postmistrza.

Sprawdź ps, czy pid to postmaster postmaster.

Zabij proces postmastera następującą komendą, zastępując „PID” numerem, który zanotowałeś. Ponownie, nie używaj kill -9lub kill -KILLpo prostu używaj zwykłego kill, tj .SIGTERM :

kill PID

Jeśli pid nie jest postmasterem postmastera, ręcznie uruchom killwszystkie postgresbackendy, które mogą nadal działać, sprawdź , czy już nie działają, a dopiero potem usuń postmaster.pid. (Należy również sprawdzić, czy postmaster.pidnie znajduje się on w pamięci współdzielonej, na której serwer mógłby działać na innej maszynie wirtualnej / hoście).


to zadziałało dla mnie!
Ton

To działa. Wystąpił problem polegający na tym, że opróżniłem kosz i wydaje się, że niektóre pliki danych prawdopodobnie tam były ... nie jestem pewien jak, ale były. Gdy zabiłem stary proces, zadziałało dobrze.
Dan L

Tak. to było na miejscu.
Amos Folarin

7
Należy wspomnieć, że po twardej awarii plik PID może przetrwać, podczas gdy proces umiera. W takim przypadku PID w pliku PID może wskazywać na proces, który nie ma nic wspólnego z Postgres. Zobacz drugą odpowiedź dla tej sprawy.
luty

2
Zwykły kill PIDnie działał dla mnie. Musiałem kill -3 PID. W moim przypadku wykonałem zamknięcie, które mogło zabić okna terminali bez odpowiedniego zatrzymania procesów. kill -3 PIDZabity proces i jego dzieci skutecznie pozwolił mi znowu zacząć postgres.
Paul Masri-Stone,

46

Inną możliwością jest to, że mocno się zamknąłeś i proces postgres zmarł bez czyszczenia pliku pid. Zdarza mi się to, gdy bateria mojego laptopa wyczerpuje się.

To rozwiązanie nie jest przeznaczone dla systemu produkcyjnego i powinieneś naprawdę upewnić się, że demon Postgres nie działa , ale używam mojego laptopa do kodowania i nie martwię się o konieczność zregenerowania moich baz danych.

Więc jeśli na tym porcie działa inny proces - lub wcale go nie ma - po prostu usuń plik pid, np

rm /usr/local/var/postgres/postmaster.pid

i postgres wkrótce zacznie działać dobrze.

Aby dowiedzieć się, czy na tym porcie działa inny proces, możesz to zrobić

ps wax | grep `head -1 /usr/local/var/postgres/postmaster.pid`

Następnie uruchomić

tail -f /usr/local/var/postgres/server.log 

aby sprawdzić, czy zadziałało. Powinieneś zobaczyć

FATAL:  lock file "postmaster.pid" already exists
HINT:  Is another postmaster (PID 933) running in data directory "/usr/local/var/postgres"?
FATAL:  lock file "postmaster.pid" already exists
HINT:  Is another postmaster (PID 933) running in data directory "/usr/local/var/postgres"?
LOG:  database system was interrupted; last known up at 2014-05-25 09:41:32 PDT
LOG:  database system was not properly shut down; automatic recovery in progress

(a przynajmniej tak właśnie zobaczyłem po wykonaniu powyższego :-))

(I naprawdę, czy Postgres nie powinien być wystarczająco inteligentny, aby zdać sobie sprawę, że PID 933 nie ma procesu i sam usunąć fałszywy plik pid?)


1
Tak było w moim przypadku. Miałem inny proces przypadkowo uruchomiony na tym samym PID, na postmaster.pidktóry wskazywał plik. Było to kilka dni po nieczystym zamknięciu (instalacja Postgres na laptopie na OSX przez homebrew).
Jesse Buchanan

1
Mój Mac zawiesił się na ekranie logowania i musiałem go wyłączyć. Skończyło się to pozostawieniem pliku postmaster.pid, który odwoływał się do PID, który przyzwyczaił się do czegoś innego przy następnym restarcie i postgres nie pojawił się. Próbowałem zabić PID (jak post polecił craig-ringer), ale to nie pomogło. Jednak rm postmaster.pidpracował dla mnie. Nie widzę żadnego uszkodzenia danych (ale w każdym razie jest to tylko maszyna programistyczna).
Steven Chanin

To samo dla mnie. Wyłączyłem komputer Mac bez zatrzymywania lokalnego serwera Rails.
Bruno Paulino,

1
Ciągle wracam do tego wątku, ilekroć się to zdarza - ponieważ nigdy nie pamiętam, gdzie jest plik pid, więc zawsze muszę to sprawdzić: P
haslo

Zdarzyło mi się to z Postgres.app. Po usunięciu ~/Library/Application Support/Postgres/data/postmaster.pidbyłem znowu gotowy do pracy.
Rob Johansen,

8

Próbowałem tego wszystkiego bezskutecznie po aktualizacji do Yosemite złamał mój postgres (zainstalowany przez homebrew).

Potem natknąłem się na ten post na blogu: http://ruckus.tumblr.com/post/100355276496/yosemite-upgrade-breaks-homebrew-installed-postgres

Najpierw musiałem utworzyć brakujące katalogi, które najwyraźniej zostały usunięte podczas aktualizacji (dzięki Apple!).

$ cd /usr/local/var/postgres

$ mkdir {pg_tblspc,pg_twophase,pg_stat_tmp}

Następnie ponownie uruchom postgres, używając normalnej sekwencji uruchamiania homebrew:

$ launchctl unload ~/Library/LaunchAgents/homebrew.mxcl.postgresql.plist

$ launchctl load ~/Library/LaunchAgents/homebrew.mxcl.postgresql.plist

Dzięki Ruckus Notes za pomoc w rozwiązaniu mojego problemu. Mam nadzieję, że to również pomaga.


4

TWARDE INSTRUKCJE REBOOTU

Miałem ten sam problem po ciężkim ponownym uruchomieniu. Po sprawdzeniu postmaster.pidpid pliku zauważyłem, że nie mam uruchomionego procesu. Nie chciałem mocno usuwać pliku .pid, zamiast tego użyłem pg-stopaliasu, który utworzyłem w swoim .bash_profile. ten alias po prostu działa

pg_ctl -D /usr/local/var/postgres stop -s -m fast

Na przykład

# psql
alias pg-start='pg_ctl -D /usr/local/var/postgres -l /usr/local/var/postgres/server.log start'
alias pg-stop='pg_ctl -D /usr/local/var/postgres stop -s -m fast'

dane wyjściowe dziennika po pg-stop

LOG:  database system was interrupted; last known up at 2016-04-25 10:51:08 PDT
LOG:  database system was not properly shut down; automatic recovery in progress
LOG:  record with zero length at 0/274FA10
LOG:  redo is not required
LOG:  database system is ready to accept connections
LOG:  autovacuum launcher started
LOG:  received smart shutdown request
LOG:  autovacuum launcher shutting down
LOG:  shutting down
LOG:  database system is shut down
LOG:  database system was shut down at 2016-04-25 13:11:04 PDT

napar

Pomyślałem, że powinienem tutaj również wspomnieć, że jeśli zainstalowałeś postgres z homebrew, powinieneś rzucić brew servicesokiem. W ten sposób wolę uruchamiać / zatrzymywać moje bazy danych.

XXXXX:~ chris$ brew services list
Name       Status  User  Plist
mongodb    stopped
postgresql started chris /Users/chris/Library/LaunchAgents/homebrew.mxcl.postgresql.plist
redis      started chris /Users/chris/Library/LaunchAgents/homebrew.mxcl.redis.plist

Informacje o naparach były właśnie tym, czego potrzebowałem, dzięki!
dnatoli

1

Ten błąd wystąpił po, jak sądzę, awarii mojego komputera. PostgreSQL nie mógł nawet uruchomić z powodu tego błędu, więc zabicie procesu nie było rozwiązaniem. Po prostu utworzyłem kopię zapasową, a następnie usunąłem postmaster.pidplik, a następnie błąd ustał i PG mógł rozpocząć od nowa.


1

Czasami pokorni pg_ctl -w restartmogą załatwić sprawę :-)


Uwielbiam, gdy najlepsza odpowiedź brzmi: jesteś skazany! NIC DOTKNIĘCIE! i wtedy jedno małe polecenie mnie uruchamia. (W moim przypadku pid /usr/pgsql/9.3/data/postmaster.pidnie był obecny w ps aux.)
Noumenon

0

Usuwanie postmaster.pid jest naprawdę całkiem przyzwoitą rzeczą do zrobienia przy każdym rozruchu, na ślepo. Tak właśnie działa mój system. Ponieważ właśnie się uruchomiłeś, wiesz, że nie ma uruchomionego procesu Postgres, a jeśli odzyskujesz po nieczystym zamknięciu, ten plik będzie tam uniemożliwiać odzyskiwanie.

Lepszym rozwiązaniem dla Postgresa byłoby umieszczenie pliku postmaster.pid w systemie plików / run, więc gwarantuje się, że zostanie usunięty przy każdym ponownym uruchomieniu. Wiele innych serwerów działa w ten sposób.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.