"FATAL: Sperrdatei" postmaster.pid "existiert bereits"

Öffentlicher Dienst Ankündigung: nie postmaster.pid löschen. Ja wirklich. Gute Möglichkeit, Datenkorruption zu bekommen.

Sie hatten bereits PostgreSQL installiert und haben das Datenverzeichnis gelöscht, ohne den laufenden Server anzuhalten. Sie haben jetzt einige Orphan PostgreSQL-Serverprozesse, die gelöschte Datendateien verwalten, sodass sie im Dateisystem nicht mehr verfügbar sind und vollständig gelöscht werden, wenn das zuletzt geöffnete Dateihandle für sie geschlossen wird. Sie können pg_ctl nicht verwenden, um den Server wie gewohnt herunterzufahren, da Sie den Cluster-Datadir gelöscht haben. Sie müssen also einfach die Prozesse beenden. Töte den Postmaster (benutze nicht kill -9, es reicht ein gewöhnlicher Kill) und der Rest wird ebenfalls heruntergefahren.

Sie können dann einen neuen Server im Datenverzeichnis für die neuen Daten von initdb starten.

Es ist sehr wahrscheinlich, dass Konflikte auftreten, wenn Sie nicht die andere ältere Version von PostgreSQL deinstallieren.

In einer Nussschale:

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

Notieren Sie die Nummer in der ersten Zeile, die das pid des Postmasters ist.

Stellen Sie mit ps sicher, dass die PID die eines Postgres-Postmasters ist.

Beenden Sie den Postmaster-Prozess mit dem folgenden Befehl und ersetzen Sie 'PID' durch die Nummer, die Sie notiert haben. Wiederum benutze weder kill -9 noch kill -KILL, sondern benutze einfach ein einfaches kill, d. H. Ein SIGTERM:

kill PID

Wenn die PID nicht die eines Postgres-Postmasters ist, kill manuell alle postgres-Backends, die möglicherweise noch ausgeführt werden, verifizieren dass sie nicht mehr ausgeführt werden, und erst dann entfernen postmaster.pid. (Sie müssen auch sicherstellen, dass sich der postmaster.pid nicht auf einem gemeinsam genutzten Speicher befindet, auf dem der Server möglicherweise auf einer anderen VM/einem anderen Host ausgeführt wird.).

Eine andere Möglichkeit ist, dass Sie ein hartes Herunterfahren hatten und der Postgres-Prozess ohne Bereinigung seiner PID-Datei abgestürzt ist. Dies passiert mir, wenn der Akku meines Laptops leer ist.

Diese Lösung ist nicht für ein Produktionssystem, und Sie sollten wirklich sicherstellen, dass der Postgres-Daemon nicht ausgeführt wird , aber ich verwende meinen Laptop zum Codieren und mache mir keine Sorgen, dass ich meinen neu generieren muss Datenbanken.

Wenn also ein anderer Prozess - oder überhaupt keiner - auf diesem Port ausgeführt wird, löschen Sie einfach die PID-Datei, z.

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

und postgres wird bald gut anlaufen.

Um herauszufinden, ob an diesem Port ein anderer Prozess ausgeführt wird, können Sie Folgendes tun

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

Dann renne

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

um zu sehen, ob es funktioniert hat. Das solltest du sehen

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

(oder zumindest habe ich das erst gesehen, nachdem ich das oben Genannte getan habe :-))

(Und sollte Postgres wirklich nicht klug genug sein, um zu erkennen, dass es mit PID 933 keinen Prozess gibt, und die gefälschte PID-Datei selbst zu entfernen?)

Ich habe das alles erfolglos versucht, nachdem ich auf Yosemite upgegradet hatte und meine Postgres (per Homebrew installiert) zerbrochen hatte.

Dann bin ich auf diesen Blog-Beitrag gestoßen: http://ruckus.tumblr.com/post/100355276496/yosemite-upgrade-breaks-homebrew-installed-postgres

Zuerst musste ich die fehlenden Verzeichnisse erstellen, die anscheinend während des Upgrades gelöscht wurden (danke Apple!).

$ cd /usr/local/var/postgres

$ mkdir {pg_tblspc,pg_twophase,pg_stat_tmp}

Dann starte postgres einfach wieder mit der normalen Homebrew-Startsequenz:

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

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

Vielen Dank an Ruckus Notes für die Hilfe bei der Lösung meines Problems. Hoffentlich hilft es dir auch.

HARTE REBOOT-ANWEISUNGEN

Ich hatte das gleiche Problem nach einem harten Neustart. Nachdem ich die PID der postmaster.pid-Datei überprüft hatte, bemerkte ich, dass kein Prozess ausgeführt wurde. Ich wollte die PID-Datei nicht hart löschen, sondern habe stattdessen einen pg-stop-Alias ​​verwendet, den ich in meinem .bash_profile erstellt hatte. Dieser Alias ​​läuft einfach

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

Als Referenz

# 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'

protokollausgabe nach 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

brauen

Ich dachte, ich sollte hier auch erwähnen, dass, wenn Sie Postgres mit Homebrew installiert haben, Sie brew services einen Blick darauf werfen sollten. So starte/stoppe ich jetzt lieber meine Datenbanken.

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

Manchmal kann der bescheidene pg_ctl -w restart den Trick :-) tun

Ich habe diesen Fehler erhalten, nachdem, wie ich glaube, mein Computer abgestürzt ist. PostgreSQL konnte aufgrund dieses Fehlers nicht einmal gestartet werden, daher war es nicht die Lösung, den Prozess zu beenden. Ich habe einfach eine Sicherungskopie erstellt und dann die postmaster.pid-Datei gelöscht. Dann wurde der Fehler gestoppt und PG konnte erneut gestartet werden.

Das Löschen von postmaster.pid ist eigentlich eine wirklich anständige Sache, die Sie bei jedem Start blind machen müssen. Das macht mein System. Da Sie gerade gebootet haben, wissen Sie, dass kein Postgres-Prozess ausgeführt wird. Wenn Sie nach einem unsauberen Herunterfahren eine Wiederherstellung durchführen, wird diese Datei Ihre Wiederherstellung verhindern.

Ein besseres Design für Postgres wäre, die Datei postmaster.pid im Dateisystem/run abzulegen, damit sie bei jedem Neustart garantiert gelöscht wird. Viele andere Server arbeiten auf diese Weise.