"FATAL: le fichier de verrouillage" postmaster.pid "existe déjà"
Je viens de réinstaller Postgres via brew install postgres
J'ai couru initdb /usr/local/var/postgres -E utf8 mais j'ai obtenu 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 -rf le dossier postgres et l'ai exécuté à nouveau:
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?
Annonce de service public: ne supprimez jamais 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 Orphan PostgreSQL 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 utiliser pg_ctl pour éteindre le serveur normalement, car vous avez supprimé le datadir du cluster. Vous devez donc simplement supprimer les processus. Tuez le postmaster (do not use kill -9, un kill ordinaire suffira) et le reste s'arrêtera aussi.
Vous pourrez alors démarrer un nouveau serveur dans datadir avec les données fraîchement initdbname __ 'd.
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 psque le pid est celui d'un postmaster.
Tuez le processus postmaster avec la commande suivante, en remplaçant «PID» par le numéro que vous avez noté. Encore une fois, n’utilisez pas kill -9 ni kill -KILL, utilisez simplement un killname__, c’est-à-dire un SIGTERM:
kill PID
Si le pid n'est pas celui d'un postmaster, vous devez manuellement killtous les postgresqui peuvent encore être en cours d'exécution, verify s'ils ne sont plus en cours d'exécution, et seulement alors / remove postmaster.pid. (Vous devez également vérifier que le postmaster.pid ne se trouve pas sur un stockage partagé sur lequel le serveur pourrait être exécuté sur une autre machine virtuelle/hôte).
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 est pas pour 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 mon ordinateur. 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?)
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 de blog: 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.
INSTRUCTIONS DE REDEMARRAGE DUR
J'ai eu ce même problème après un redémarrage difficile. Après avoir vérifié le pid du fichier postmaster.pid, 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 alias pg-stop que j'avais créé dans mon .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 jeter un coup d'œil à brew services. 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
Parfois, l'humble pg_ctl -w restart peut faire l'affaire :-)
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 fichier postmaster.pid, puis l'erreur s'est arrêtée et PG a pu redémarrer.
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.