FATAL: arquivo de bloqueio "postmaster.pid" está vazio

Instalação
1

Pela primeira vez, vejo o seguinte erro ao tentar reconstruir.

2022-10-04 14:39:49.780 UTC [1700] FATAL:  lock file "postmaster.pid" is empty
2022-10-04 14:39:49.780 UTC [1700] HINT:  Either another server is starting, or the lock file is the remnant of a previous server startup crash.

Eu obviamente consigo ler a dica, mas não sei como proceder. Alguém pode oferecer alguma informação?

2

Quando isso está acontecendo? Esta é uma instalação padrão?

3

Instalação padrão e após executar ./launcher rebuild app

4

Talvez tente um

 ./launcher start app

Isso funcionou antes?

É um erro ou um aviso. Você tentou abrir no seu navegador?

O que o

 docker ps

diz

5

Resposta para ./launcher start app:

57c2a0746e93
Nada a fazer, seu contêiner já iniciou!

E então no navegador eu recebo 502 Bad Gateway.

6

saída do docker ps

CONTAINER ID   IMAGE                 COMMAND        CREATED        STATUS          PORTS                                                                                                                 NAMES
57c2a0746e93   local_discourse/app   “/sbin/boot”   6 meses atrás   Subindo há 16 minutos   0.0.0.0:80->80/tcp, :::80->80/tcp, 0.0.0.0:443->443/tcp, :::443->443/tcp, 0.0.0.0:5432->5432/tcp, :::5432->5432/tcp   app
7

Isso é estranho. Acho que vou reiniciar e reconstruir novamente.

Ou talvez

   ./launcher stop app; ./launcher rebuild app

Você está executando um contêiner antigo, não um que você acabou de construir (criado há 6 meses).

E talvez tenha havido alguns outros erros na reconstrução que você não percebeu.

8

Mesmo resultado

2022-10-04 15:26:43.452 UTC [1699] FATAL:  lock file \"postmaster.pid\" is empty
2022-10-04 15:26:43.452 UTC [1699] HINT:  Either another server is starting, or the lock file is the remnant of a previous server startup crash.
9

Não há dados suficientes aqui para depurar.

Isso está acontecendo porque o processo de build pensa que o PG já está em execução, então talvez algo sobre o processo de upgrade do PG esteja incorreto. Você pode incluir logs completos do launcher (removendo senhas) para que possamos ver o que está acontecendo.

10

Talvez ajude olhar para um sistema que está funcionando corretamente. Vejo meu lockfile aqui:

# ls -l /var/discourse/shared/standalone/postgres_data/postmaster.pid
-rw------- 1 systemd-resolve input 92 Nov 15 16:20 /var/discourse/shared/standalone/postgres_data/postmaster.pid

e 15 de novembro é a data em que iniciei o aplicativo pela última vez. Se eu entrar no aplicativo, posso ver os processos do postgres:

# cd /var/discourse/
# ./launcher enter app
x86_64 arch detected.
# ps auxfc|egrep -1 postm
root        45  0.0  0.0   2332     0 ?        S    Nov15   0:00      \_ svlogd
postgres    48  0.0  0.1 213160  1784 ?        S    Nov15   0:27      \_ postmaster
postgres    67  0.0  2.6 213380 26924 ?        Ss   Nov15   0:34          \_ postmaster
postgres    68  0.0  0.4 213292  4236 ?        Ss   Nov15   0:15          \_ postmaster
postgres    69  0.0  0.1 213160  1068 ?        Ss   Nov15   3:44          \_ postmaster
postgres    70  0.0  0.1 213840  1520 ?        Ss   Nov15   0:16          \_ postmaster
postgres    71  0.0  0.0  68184   380 ?        Ss   Nov15   0:56          \_ postmaster
postgres    72  0.0  0.0 213716   468 ?        Ss   Nov15   0:00          \_ postmaster
postgres    92  0.0  0.0 225364   324 ?        Ss   Nov15   0:01          \_ postmaster
postgres   176  0.0  0.1 217944  1484 ?        Ss   Nov15   0:01          \_ postmaster
postgres  9126  0.0  0.7 215052  7336 ?        Ss   Nov16   0:19          \_ postmaster
postgres  1574  0.0  5.7 223540 58300 ?        Ss   17:28   0:00          \_ postmaster
postgres  1973  0.0  3.3 221032 33960 ?        Ss   17:34   0:00          \_ postmaster
postgres  2320  0.1  3.5 218080 36120 ?        Ss   17:39   0:00          \_ postmaster
postgres  2321  0.1  2.9 218068 29928 ?        Ss   17:39   0:00          \_ postmaster
postgres  2336  0.0  1.4 215052 14340 ?        Ss   17:40   0:00          \_ postmaster
# exit

Se eu parasse o aplicativo, esperaria não ver nenhum lockfile naquele local e nenhum processo postgres em execução. (Eu, é claro, precisaria executar o comando ps diretamente no host, porque o contêiner não estaria mais em execução.)

Na sua situação, acho que é o que eu faria primeiro: parar o aplicativo e verificar se nenhum processo postgres está em execução. Parece possível que você tenha duas instâncias em execução que estão colidindo uma com a outra.

É improvável, mas também é possível que o disco tenha enchedo e é por isso que o lockfile está vazio. Ou talvez haja um problema de permissão de alguma forma.

Editar: dentro do contêiner, o lockfile tem um local e propriedade diferentes:

# ./launcher enter app
x86_64 arch detected.
# ls -l /shared/postgres_data/postmaster.pid
-rw------- 1 postgres postgres 92 Nov 15 16:20 /shared/postgres_data/postmaster.pid
# exit
logout
#

Como Sam observa, precisaríamos ver mais informações.

1 curtida