“FATAL: arquivo de bloqueio” postmaster.pid “já existe”

Question

Eu apenas reinstalei o postgres via brew install postgres

Eu corri initdb /usr/local/var/postgres -E utf8 mas comprei isto:

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

então, eu rm -rf da pasta postgres e executei novamente:

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

disse que tudo estava bem:

Success. You can now start the database server using:

    postgres -D /usr/local/var/postgres

então, eu corri o comando e recebi:

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

Agora, quando olho meu Activity Monitor, vejo seis instâncias de postgress.

Como corrijo isso?

    

Answer 1

Anúncio de serviço público: nunca exclua postmaster.pid . Mesmo. Ótima maneira de obter corrupção de dados.

Você já tinha o PostgreSQL instalado e excluiu o diretório de dados sem interromper o servidor em execução. Portanto, agora você tem alguns processos órfãos do servidor PostgreSQL que estão gerenciando arquivos de dados que foram excluídos, para que eles não sejam mais acessíveis no sistema de arquivos e serão totalmente excluídos quando a última manipulação de arquivos abertos para eles estiver fechada. Você não pode usar pg_ctl para desligar o servidor como de costume porque você excluiu o datadir do cluster, então você deve simplesmente eliminar os processos. Matar o postmaster (fazer não usar kill -9 , apenas uma morte comum serve) e o resto também será desligado.

Você poderá, então, iniciar um novo servidor no datadir com base nos dados recentes do initdb '.

É altamente provável que você experimente conflitos na pista, a menos que você desinstale a outra versão mais antiga do PostgreSQL.

Resumindo:

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

Anote o número na primeira linha, que é o pid do postmaster.

Verifique com ps que o pid é o de um postmaster postgres.

Mate o processo postmaster com o seguinte comando, substituindo 'PID' pelo número anotado. Novamente, não use kill -9 ou kill -KILL , use apenas kill , ou seja, SIGTERM :

kill PID

Se o pid não for o de um postmaster postgres, manualmente kill any postgres backends que ainda podem estar em execução, verificarão se eles não estão mais em execução e somente então remova postmaster.pid . (Você também deve verificar se o postmaster.pid não está no armazenamento compartilhado onde o servidor pode estar sendo executado em alguma outra VM / host).

    

Answer 2

Outra possibilidade é que você teve um desligamento e o processo postgres morreu sem limpar o arquivo pid. Isso acontece comigo quando a bateria do meu laptop morre.

Esta solução não é para um sistema de produção, e você deve ter certeza de que o daemon postgres não está rodando , mas eu uso meu laptop para codificação e estou Não estou preocupado com a necessidade de regenerar meus bancos de dados.

Portanto, se outro processo - ou nenhum - estiver sendo executado nessa porta, basta excluir o arquivo pid, por exemplo,

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

e o postgres será iniciado em breve.

Para descobrir se outro processo está sendo executado nessa porta, você pode fazer

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

Em seguida, execute

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

para ver se funcionou. Você deveria ver

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 pelo menos é o que acabei de ver depois que fiz o seguinte :-))

(E realmente, o Postgres não deveria ser inteligente o suficiente para perceber que não há processo com o PID 933 e remover o falso arquivo pid por conta própria?)

    

Answer 3

Eu tentei tudo isso sem sucesso depois de atualizar para o Yosemite que quebrou o meu postgres (instalado via homebrew).

Então eu tropecei neste post: link

Primeiro eu precisei criar os diretórios perdidos que aparentemente foram eliminados durante a atualização (graças à Apple!).

$ cd /usr/local/var/postgres

$ mkdir {pg_tblspc,pg_twophase,pg_stat_tmp}

Em seguida, inicie o postgres novamente usando a sequência normal de lançamento de homebrews:

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

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

Obrigado Ruckus Notes por ajudar a resolver meu problema. Espero que ajude você também.

    

Answer 4

INSTRUÇÕES DE REINICIALIZAÇÃO HARDANA

Eu tive esse mesmo problema depois de uma reinicialização difícil. Depois de verificar o pid do arquivo postmaster.pid , percebi que não tinha nenhum processo em execução. Não queria excluir o arquivo .pid, em vez disso, usei um pg-stop alias que criei no meu .bash_profile . esse alias é executado

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

Para referência

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

saída de log apó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

cerveja

Eu pensei que eu também deveria mencionar aqui que se você instalou o postgres com o homebrew você deve dar um look a brew services . É assim que eu prefiro iniciar / parar meus bancos de dados.

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

    

Answer 5

Recebi este erro depois que o meu computador falhou. O PostgreSQL não pôde nem iniciar por causa desse erro, então matar o processo não foi a solução. Eu simplesmente fiz um backup e depois deletei o arquivo postmaster.pid e então o erro parou e o PG foi capaz de começar de novo.

    

Answer 6

Às vezes, o humilde pg_ctl -w restart pode fazer o truque: -)

    

Answer 7

Excluir o postmaster.pid é realmente uma coisa realmente decente para fazer em cada inicialização, às cegas. É o que meu sistema faz. Como você acabou de inicializar, sabe que não há nenhum processo do Postgres em execução e, se estiver se recuperando de um desligamento impuro, esse arquivo estará lá impedindo sua recuperação.

Um design melhor para o Postgres seria colocar o arquivo postmaster.pid no sistema de arquivos / run, portanto, é garantido que ele seja deletado a cada reinicialização. Muitos outros servidores funcionam dessa maneira.