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


68

Ich habe gerade postgres über neu installiert brew install postgres

Ich bin gelaufen, habe initdb /usr/local/var/postgres -E utf8aber folgendes:

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

rm -rfAlso habe ich den Postgres-Ordner und lief es noch einmal:

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

es hieß alles in ordnung:

Success. You can now start the database server using:

    postgres -D /usr/local/var/postgres

Also habe ich diesen Befehl ausgeführt und Folgendes erhalten:

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

Wenn ich jetzt auf meinen Aktivitätsmonitor schaue, sehe ich 6 Postgress-Instanzen.

Wie behebe ich das?


Sie sehen wahrscheinlich eine Instanz von postgresmit einem Postmaster und fünf Utility-Backends. PostgreSQL ist eine Multiprozessarchitektur.
Craig Ringer

Antworten:


104

Öffentliche Bekanntmachung: niemals löschen postmaster.pid. 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 verwaiste 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_ctlden Server nicht wie gewohnt herunterfahren, da Sie das Cluster-Datenverzeichnis gelöscht haben. Sie müssen also einfach die Prozesse beenden. Töte den Postmeister ( benutze ihn nichtkill -9 , es reicht ein gewöhnlicher Kill) und der Rest wird ebenfalls heruntergefahren.

Sie können dann einen neuen Server im Datadir gegen die aktuellen initdbDaten 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 die PID des Postmasters ist.

Stellen Sie sicher , mit , psdass die pid die eines Postgres Postmeister ist.

Beenden Sie den Postmaster-Prozess mit dem folgenden Befehl und ersetzen Sie 'PID' durch die Nummer, die Sie notiert haben. Auch hier nicht verwenden kill -9oder kill -KILLnur eine einfache Verwendung kill, dh einSIGTERM :

kill PID

Wenn die PID nicht die eines Postgres-Postmasters ist , überprüfen Sie manuell killalle postgresnoch laufenden Backends, ob sie nicht mehr ausgeführt werden, und entfernen Sie sie erst dannpostmaster.pid . (Sie müssen auch sicherstellen, dass sich das postmaster.pidnicht auf einem gemeinsam genutzten Speicher befindet, auf dem der Server möglicherweise auf einer anderen VM / einem anderen Host ausgeführt wird.)


das hat bei mir geklappt!
Tone

Das funktioniert. Hatte ein Problem, bei dem ich meinen Papierkorb geleert habe und es scheint, dass sich dort wahrscheinlich einige Datendateien befanden ... nicht sicher, wie, aber sie waren. Nachdem ich den alten Prozess beendet hatte, funktionierte er einwandfrei.
Dan L

Ja. das war genau richtig.
Amos Folarin

7
Es sollte erwähnt werden, dass nach einem schweren Absturz die PID-Datei überleben kann, während der Prozess abbricht. In diesem Fall kann die PID in der PID-Datei auf einen Prozess verweisen, der nichts mit Postgres zu tun hat. Siehe zweite Antwort für diesen Fall.
Febeling

2
Eine Ebene kill PIDhat bei mir nicht funktioniert. Ich brauchte kill -3 PID. In meinem Fall hatte ich einen Shutdown durchgeführt, der möglicherweise Terminalfenster getötet hat, ohne die Prozesse ordnungsgemäß zu stoppen. Sie kill -3 PIDhaben den Prozess getötet und ihre Kinder haben mich erfolgreich wieder mit Postgres beginnen lassen.
Paul Masri-Stone

46

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 Produktivsystem gedacht, 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 meine Datenbanken neu generieren muss .

Wenn auf diesem Port ein anderer oder gar kein Prozess 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 wirklich, sollte Postgres nicht klug genug sein, um zu erkennen, dass es mit PID 933 keinen Prozess gibt, und die gefälschte PID-Datei selbst entfernen?)


1
Das war bei mir der Fall. Ich hatte einen anderen Prozess, der zufällig auf der gleichen PID lief, auf die die postmaster.pidDatei zeigte. Dies war einige Tage nach einem unsauberen Herunterfahren (Laptop-Installation von Postgres unter OSX über Homebrew).
Jesse Buchanan

1
Mein Mac hing auf dem Anmeldebildschirm und ich musste ihn ausschalten. Das endete damit, dass eine postmaster.pid-Datei hinterlassen wurde, die auf eine PID verwies, die beim nächsten Neustart für etwas anderes verwendet wurde, und postgres nicht auftauchte. Ich habe versucht, die PID zu töten (wie der Beitrag von Craig-Ringer empfohlen), aber das hat nicht geholfen. Hat aber rm postmaster.pidbei mir geklappt. Ich sehe keine Datenbeschädigung (aber in jedem Fall ist dies nur eine Entwicklungsmaschine).
Steven Chanin

Das Gleiche für mich. Ich hatte meinen Mac heruntergefahren, ohne den lokalen Rails-Server anzuhalten.
Bruno Paulino

1
Ich komme immer wieder auf diesen Thread zurück, wenn dies passiert - da ich mich nie erinnern kann, wo sich die PID-Datei befindet, muss ich sie immer nachschlagen: P
haslo

Das ist mir mit der Postgres.app passiert. Nach dem Löschen war ~/Library/Application Support/Postgres/data/postmaster.pidich wieder einsatzbereit.
Rob Johansen

8

Ich habe das alles ohne Erfolg versucht, nachdem ich auf Yosemite upgegradet 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.


4

HARTE REBOOT-ANWEISUNGEN

Ich hatte das gleiche Problem nach einem harten Neustart. Nachdem postmaster.pidich die PID der Datei überprüft hatte , bemerkte ich, dass kein Prozess ausgeführt wurde. Ich wollte die .pid-Datei nicht hart löschen, sondern habe einen pg-stopAlias ​​verwendet, den ich in meinem erstellt hatte .bash_profile. 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 serviceseinen 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

Die Brauinfo war genau das, was ich brauchte, danke!
dnatoli

1

Ich habe diesen Fehler nach einem Absturz meines Computers erhalten. 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.pidDatei gelöscht. Dann wurde der Fehler gestoppt und PG konnte erneut gestartet werden.


1

Manchmal können die Demütigen pg_ctl -w restartden Trick machen :-)


Liebe, wenn die beste Antwort lautet: DU BIST VERDOOMT! TOUCH NICHTS! und dann bringt mich ein kleiner Befehl zum Laufen. (In meinem Fall war die pid in /usr/pgsql/9.3/data/postmaster.pidnicht in ps aux.)
Noumenon

0

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 hochgefahren sind, 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.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.