“FATAL: le fichier de verrouillage” postmaster.pid “existe déjà”

69

Je viens de réinstaller Postgres via brew install postgres

J'ai couru initdb /usr/local/var/postgres -E utf8mais j'ai eu ceci:

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

alors, j'ai rm -rfle dossier postgres et l' ai relancé:

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

il a dit que tout allait bien:

Success. You can now start the database server using:

    postgres -D /usr/local/var/postgres

alors, j'ai exécuté cette commande et obtenu:

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

Maintenant, lorsque je regarde mon moniteur d'activité, je peux voir 6 instances de postgress.

Comment puis-je réparer ça?

AdamT
la source
Vous voyez probablement une instance de postgresavec un postmaster et cinq utilitaires. PostgreSQL est une architecture multi-processus.
Craig Ringer

Réponses:

105

Annonce de service public: ne jamais supprimer postmaster.pid. Vraiment. Excellent moyen d'obtenir la corruption de données.

PostgreSQL était déjà installé et vous avez supprimé le répertoire de données sans arrêter le serveur en cours d'exécution. Vous avez donc maintenant des processus serveur PostgreSQL orphelins qui gèrent les fichiers de données qui ont été supprimés. Ils ne sont donc plus accessibles dans le système de fichiers et seront complètement supprimés lorsque le dernier descripteur de fichier ouvert leur sera fermé. Vous ne pouvez pas pg_ctlarrêter le serveur normalement, car vous avez supprimé le datadir du cluster. Vous devez donc simplement tuer les processus. Tuez le maître de poste (ne l' utilisez paskill -9 , un meurtre ordinaire suffira) et le reste s'arrêtera aussi.

Vous pourrez alors démarrer un nouveau serveur dans le datadir avec les initdbdonnées fraîches .

Il est fort probable que vous rencontriez des conflits sur la piste à moins de désinstaller l'ancienne version de PostgreSQL.

En un mot:

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

Notez le numéro sur la première ligne, qui est le pid du postmaster.

Vérifiez avec pscela que le pid est celui d'un postmaster postmaster.

Tuez le processus postmaster avec la commande suivante, en remplaçant «PID» par le numéro que vous avez noté. Encore une fois, ne pas utiliser kill -9ou kill -KILLsimplement utiliser un simple kill, c'est-à-dire unSIGTERM :

kill PID

Si le pid n'est pas celui d'un postmaster postmaster, définissez manuellement killtous les postgresbackends pouvant encore être en cours d'exécution, vérifiez qu'ils ne le sont plus, puis supprimez-les postmaster.pid. (Vous devez également vérifier que le postmaster.pidne se trouve pas sur un stockage partagé sur lequel le serveur pourrait être exécuté sur une autre machine virtuelle / hôte).

Craig Ringer
la source
cela a fonctionné pour moi!
Ton
Cela marche. J'ai eu un problème où j'ai vidé ma corbeille et il semble que certains fichiers de données étaient probablement là-dedans ... je ne sais pas comment, mais ils l'étaient. Une fois que j'ai tué l'ancien processus, cela a bien fonctionné.
Dan L
Ouais. c'était parfait.
Amos Folarin
7
Il convient de mentionner qu'après un crash dur, le fichier PID peut survivre pendant la mort du processus. Dans ce cas, le PID dans le fichier PID peut indiquer un processus qui n'a rien à voir avec Postgres. Voir la deuxième réponse pour ce cas.
Febeling
2
Une plaine kill PIDn'a pas fonctionné pour moi. J'avais besoin kill -3 PID. Dans mon cas, j’ai fait un arrêt qui peut avoir tué des fenêtres de terminal sans arrêter les processus correctement. Le kill -3 PIDprocessus a été tué et ses enfants m'ont permis de relancer postgres.
Paul Masri-Stone
46

Une autre possibilité est que vous ayez eu un arrêt brutal et que le processus postgres soit mort sans nettoyer son fichier pid. Cela m’arrive quand la batterie de mon ordinateur portable meurt.

Cette solution n'est pas destinée à un système de production et vous devez vraiment vous assurer que le démon postgres ne fonctionne pas , mais j'utilise mon ordinateur portable pour le codage et je ne crains pas de devoir régénérer mes bases de données.

Donc, si un autre processus - ou aucun du tout - est en cours d'exécution sur ce port, supprimez simplement le fichier pid, par exemple

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

et postgres va bientôt commencer bien.

Pour savoir si un autre processus est en cours d'exécution sur ce port, vous pouvez effectuer

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

Puis courir

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

pour voir si cela a fonctionné. Tu devrais voir

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

(ou du moins c'est ce que je viens de voir après avoir fait ce qui précède :-))

(Et vraiment, Postgres ne devrait-il pas être assez intelligent pour se rendre compte qu'il n'y a pas de processus avec le PID 933 et supprimer le fichier pid bidon tout seul?)

AlexChaffee
la source
1
C'était le cas pour moi. Un autre processus fonctionnait par hasard sur le même PID que le postmaster.pidfichier désignait. C'était plusieurs jours après un arrêt impropre (installation de Postgres sous OSX sur un ordinateur portable via homebrew).
Jesse Buchanan
1
Mon mac était accroché à l'écran de connexion et je devais l'éteindre. Cela a fini par laisser un fichier postmaster.pid qui faisait référence à un PID utilisé pour autre chose lors du prochain redémarrage et que postgres ne s'afficherait pas. J'ai essayé de tuer le PID (comme le post de craig-ringer recommandé), mais cela n'a pas aidé. Cependant, a rm postmaster.pidtravaillé pour moi. Je ne vois aucune corruption de données (mais dans tous les cas, il ne s'agit que d'une machine de développement).
Steven Chanin
Même chose pour moi. J'avais arrêté mon Mac sans arrêter le serveur Rails local.
Bruno Paulino
1
Je reviens sans cesse sur ce sujet chaque fois que cela se produit - car je ne me souviens jamais de l'emplacement du fichier pid, je dois donc toujours le rechercher: P
haslo
Cela m'est arrivé avec le Postgres.app. Après avoir supprimé, ~/Library/Application Support/Postgres/data/postmaster.pidj'étais à nouveau opérationnel.
Rob Johansen
8

J'ai essayé tout cela en vain après la mise à niveau vers Yosemite qui a cassé mon postgres (installé via homebrew).

Puis je suis tombé sur cet article: http://ruckus.tumblr.com/post/100355276496/yosemite-upgrade-breaks-homebrew-installed-postgres

Tout d'abord, je devais créer les répertoires manquants qui avaient apparemment été supprimés lors de la mise à niveau (merci à Apple!).

$ cd /usr/local/var/postgres

$ mkdir {pg_tblspc,pg_twophase,pg_stat_tmp}

Ensuite, relancez simplement postgres en utilisant la séquence de lancement homebrew normale:

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

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

Merci Ruckus Notes pour avoir aidé à résoudre mon problème. J'espère que cela vous aidera aussi.

Billy G
la source
4

INSTRUCTIONS DE REDEMARRAGE DUR

J'ai eu ce même problème après un redémarrage difficile. Après avoir vérifié le postmaster.pidpid du fichier, j'ai remarqué qu'aucun processus n'était en cours d'exécution. Je ne voulais pas supprimer le fichier .pid, mais j’ai utilisé un pg-stopalias que j’avais créé dans mon fichier .pid .bash_profile. cet alias ne fait que courir

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

Pour référence

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

enregistrer la sortie après 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

brasser

Je pensais que je devrais également mentionner ici que si vous avez installé Postgres avec homebrew, vous devriez brew servicesjeter un coup d'œil. C’est maintenant comment je préfère démarrer / arrêter mes bases de données.

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
Chris Miller
la source
L'information de brassage était exactement ce dont j'avais besoin, merci!
dnatoli
1

J'ai reçu cette erreur après, je pense, mon ordinateur est tombé en panne. PostgreSQL n'a même pas pu démarrer à cause de cette erreur, si bien que tuer le processus n'était pas la solution. J'ai simplement sauvegardé puis supprimé le postmaster.pidfichier, puis l'erreur s'est arrêtée et PG a pu redémarrer.

Jeff
la source
1

Parfois, les humbles pg_ctl -w restartpeuvent faire l'affaire :-)

sekmo
la source
Amour quand la réponse du haut est que vous êtes condamné! Ne touchez rien! et puis une petite commande me fait courir. (Dans mon cas, le pid in /usr/pgsql/9.3/data/postmaster.pidn'était pas présent dans le ps aux.)
Noumenon
0

La suppression de postmaster.pid est en réalité une chose vraiment décente à faire à chaque démarrage, à l’aveugle. C'est ce que mon système fait. Parce que vous venez de démarrer, vous savez qu’aucun processus Postgres n’est en cours d’exécution, et si vous récupérez après un arrêt impropre, ce fichier empêchera votre récupération.

Une meilleure conception pour Postgres consisterait à placer le fichier postmaster.pid dans le système de fichiers / run, afin de garantir sa suppression à chaque redémarrage. Beaucoup d'autres serveurs fonctionnent de cette façon.

Giraffedata
la source