PostgreSQL travado durante a reconstrução

Instalação
1

Olá a todos,

Estou encontrando um problema com a inicialização do PostgreSQL ao tentar reconstruir meu aplicativo e espero obter ajuda.

Aqui está o log, ele ficou preso neste status por mais de 30 minutos.

Status: Image is up to date for discourse/base:2.0.20240825-0027
docker.io/discourse/base:2.0.20240825-0027
/usr/local/lib/ruby/gems/3.3.0/gems/pups-1.2.1/lib/pups.rb
/usr/local/bin/pups --stdin
I, [2024-08-26T17:16:15.344712 #1]  INFO -- : Reading from stdin
I, [2024-08-26T17:16:15.357924 #1]  INFO -- : File > /etc/service/postgres/run  chmod: +x  chown:
I, [2024-08-26T17:16:15.362740 #1]  INFO -- : File > /etc/service/postgres/log/run  chmod: +x  chown:
I, [2024-08-26T17:16:15.367767 #1]  INFO -- : File > /etc/runit/3.d/99-postgres  chmod: +x  chown:
I, [2024-08-26T17:16:15.372845 #1]  INFO -- : File > /root/install_postgres  chmod: +x  chown:
I, [2024-08-26T17:16:15.377501 #1]  INFO -- : File > /root/upgrade_postgres  chmod: +x  chown:
I, [2024-08-26T17:16:15.377876 #1]  INFO -- : Replacing data_directory = '/var/lib/postgresql/13/main' with data_directory = '/shared/postgres_data' in /etc/postgresql/13/main/postgresql.conf
I, [2024-08-26T17:16:15.378854 #1]  INFO -- : Replacing (?-mix:#?listen_addresses *=.*) with listen_addresses = '*' in /etc/postgresql/13/main/postgresql.conf
I, [2024-08-26T17:16:15.379386 #1]  INFO -- : Replacing (?-mix:#?synchronous_commit *=.*) with synchronous_commit = $db_synchronous_commit in /etc/postgresql/13/main/postgresql.conf
I, [2024-08-26T17:16:15.379835 #1]  INFO -- : Replacing (?-mix:#?shared_buffers *=.*) with shared_buffers = $db_shared_buffers in /etc/postgresql/13/main/postgresql.conf
I, [2024-08-26T17:16:15.380263 #1]  INFO -- : Replacing (?-mix:#?work_mem *=.*) with work_mem = $db_work_mem in /etc/postgresql/13/main/postgresql.conf
I, [2024-08-26T17:16:15.380761 #1]  INFO -- : Replacing (?-mix:#?default_text_search_config *=.*) with default_text_search_config = '$db_default_text_search_config' in /etc/postgresql/13/main/postgresql.conf
I, [2024-08-26T17:16:15.381203 #1]  INFO -- : Replacing (?-mix:#?checkpoint_segments *=.*) with checkpoint_segments = $db_checkpoint_segments in /etc/postgresql/13/main/postgresql.conf
I, [2024-08-26T17:16:15.381901 #1]  INFO -- : Replacing (?-mix:#?logging_collector *=.*) with logging_collector = $db_logging_collector in /etc/postgresql/13/main/postgresql.conf
I, [2024-08-26T17:16:15.382352 #1]  INFO -- : Replacing (?-mix:#?log_min_duration_statement *=.*) with log_min_duration_statement = $db_log_min_duration_statement in /etc/postgresql/13/main/postgresql.conf
I, [2024-08-26T17:16:15.382802 #1]  INFO -- : Replacing (?-mix:^#local +replication +postgres +peer$) with local replication postgres  peer in /etc/postgresql/13/main/pg_hba.conf
I, [2024-08-26T17:16:15.383231 #1]  INFO -- : Replacing (?-mix:^host.*all.*all.*127.*$) with host all all 0.0.0.0/0 md5 in /etc/postgresql/13/main/pg_hba.conf
I, [2024-08-26T17:16:15.383604 #1]  INFO -- : Replacing (?-mix:^host.*all.*all.*::1\/128.*$) with host all all ::/0 md5 in /etc/postgresql/13/main/pg_hba.conf
I, [2024-08-26T17:16:15.384079 #1]  INFO -- : > if [ -f /root/install_postgres ]; then
  /root/install_postgres && rm -f /root/install_postgres
elif [ -e /shared/postgres_run/.s.PGSQL.5432 ]; then
  socat /dev/null UNIX-CONNECT:/shared/postgres_run/.s.PGSQL.5432 || exit 0 && echo postgres already running stop container ; exit 1
fi

2024/08/26 17:16:15 socat[28] E connect(, AF=1 "/shared/postgres_run/.s.PGSQL.5432", 36): Connection refused
I, [2024-08-26T17:16:15.452500 #1]  INFO -- : Generating locales (this might take a while)...
Generation complete.

I, [2024-08-26T17:16:15.453058 #1]  INFO -- : > HOME=/var/lib/postgresql USER=postgres exec chpst -u postgres:postgres:ssl-cert -U postgres:postgres:ssl-cert /usr/lib/postgresql/13/bin/postmaster -D /etc/postgresql/13/main
I, [2024-08-26T17:16:15.455944 #1]  INFO -- : Terminating async processes
2024-08-26 17:16:15.500 UTC [30] LOG:  starting PostgreSQL 13.16 (Debian 13.16-1.pgdg120+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 12.2.0-14) 12.2.0, 64-bit
2024-08-26 17:16:15.501 UTC [30] LOG:  listening on IPv4 address "0.0.0.0", port 5432
2024-08-26 17:16:15.501 UTC [30] LOG:  listening on IPv6 address "::", port 5432
2024-08-26 17:16:15.507 UTC [30] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2024-08-26 17:16:15.516 UTC [31] LOG:  database system was interrupted; last known up at 2024-08-26 17:10:28 UTC
2024-08-26 17:16:15.769 UTC [31] LOG:  database system was not properly shut down; automatic recovery in progress
2024-08-26 17:16:15.774 UTC [31] LOG:  redo starts at 18F/E62D1458
2024-08-26 17:16:15.774 UTC [31] LOG:  invalid record length at 18F/E62D1490: wanted 24, got 0
2024-08-26 17:16:15.774 UTC [31] LOG:  redo done at 18F/E62D1458
2024-08-26 17:16:15.809 UTC [30] LOG:  database system is ready to accept connections```
2

Então ele não foi desligado corretamente e tentou consertar as coisas, e ele acha que consertou.

Talvez use Control-C para sair e veja se consegue executar ./launcher start app para colocar o contêiner antigo em funcionamento novamente.

Se funcionar, então você pode tentar novamente ./launcher stop app e depois reconstruir.

3 curtidas
3

Tenho encontrado o mesmo problema tentando reconstruir nos últimos dias. Não consigo fazer o Discourse rodar ou reconstruir sem problemas.

Tentei usar a capacidade de iniciar/parar e não pareceu funcionar. A VM em si também foi reiniciada algumas vezes. Ela continua travando naquela linha sobre o banco de dados pronto para aceitar conexões.

4

O Control-C não funcionou e tentei muitas coisas diferentes, incluindo reverter para versões antigas, mas assim que tentei a reconstrução, ela travou exatamente no mesmo lugar.

5

Quantos GB de RAM você tem? Sua conexão de rede está lenta?

6

para o meu problema… bastante RAM… 8 GB. A rede está boa

7

4 GB de RAM, verifiquei a rede, o uso do disco, o uso da CPU, o uso da RAM, tudo parece ok.

8

Consegui progredir mais. Em /var/discourse/ no meu servidor, fiz o checkout do commit b1108913820edd27f869634d0fc654639758889a. Este commit é de alguns dias atrás e não possui estes três commits (1, 2, 3) no histórico do discourse_docker. Suspeito que uma dessas alterações seja a razão para o problema de travamento do postgres.

Enfim, finalmente consegui colocar o aplicativo de volta. Foi uma experiência horrível kkk

3 curtidas
11

Mesmo problema aqui ao atualizar de 3.3.0 para 3.3.1. A atualização fica presa na mesma linha de log (o sistema de banco de dados está pronto para aceitar conexões).

Reiniciar ajuda ou apenas matar o processo de atualização e executar ./launcher start app. A nova versão 3.3.1 é exibida. Mas não tenho certeza se este é um procedimento sensato.

13

Então são quatro pessoas com um problema, eu acho.

Aqueles de vocês que tiveram problemas estavam no ARM ou no Intel?

1 curtida
14

Essa é uma ótima pergunta.

Acabei de fazer uma nova instalação em uma nova VM do Digital Ocean e, em seguida, executei uma reconstrução e funcionou perfeitamente.

15

Estou usando Intel.
A maneira como resolvi o problema foi iniciar um novo droplet e fazer uma instalação limpa, restaurar o backup e, em seguida, a reconstrução funciona bem.
Também tenho um backup de uma versão funcional (que está em uma versão um pouco mais antiga), mas assim que atualizei para a versão mais recente via reconstrução, encontrei o mesmo problema, então suspeito que há algo introduzido com um commit recente e quebra apenas a atualização da versão antiga para a nova.

1 curtida
16

Puxa.

Hmm. Vou ver se tenho um site que não me importo se cair.

Acho que você tem uma instalação padrão de 1 contêiner. Vou ver se consigo encontrar uma dessas.

17

Apenas atualizando este tópico, pois também vi este problema desde o commit acima. Tentei tudo o que foi sugerido acima para resolver o problema.

2 curtidas
18

x86. Estou no Ubuntu Bionic como sistema operacional host… talvez isso seja relevante. Não tenho certeza de qual é o sistema operacional dos outros.

19

Já passou mais de um ano do fim da vida útil (EOL). https://ubuntu.com/blog/ubuntu-18-04-eol-for-devices.

Não é cedo demais para criar uma nova VM e migrar para lá.

4 curtidas
20

Apenas mais algumas informações para ajudar a investigar o problema.

Estou vendo isso em um host executando Ubuntu 18.04.6, mas outro host também foi atualizado hoje com a mesma versão do Ubuntu e a reconstrução do Discourse progrediu normalmente.

Vou atualizar o Ubuntu no host afetado e ver se isso ajuda. Manterei todos informados.

2 curtidas
21

Para aqueles que forem afetados, você pode executar o comando ls -lahn /var/discourse/shared/standalone/ | grep -E \"postgres|redis\" e me informar se a saída difere da abaixo?

drwxr-xr-x  2  101 104 4.0K Aug 29 01:33 postgres_backup
drwx------ 19  101 104 4.0K Aug 29 01:42 postgres_data
drwxrwxr-x  3  101 104 4.0K Aug 29 01:42 postgres_run
drwxr-xr-x  2  103 106 4.0K Aug 29 01:38 redis_data
1 curtida
22 
# ls -lahn /var/discourse/shared/standalone/ | grep -E \"postgres|redis\" 
drwxr-xr-x  2  101 104 4.0K Dec 26  2019 postgres_backup
drwx------ 19  101 104 4.0K Aug 28 03:59 postgres_data
drwxrwxr-x  5  101 104 4.0K Aug 28 03:59 postgres_run
drwxr-xr-x  2  103 106 4.0K Aug 29 03:59 redis_data
2 curtidas
23

Saída da VM com problema de reconstrução:

drwxr-xr-x  2  101 104 4.0K Jun 15  2020 postgres_backup
drwx------ 19  101 104 4.0K May  3  2022 postgres_data
drwxrwsr-x  5  101 104 4.0K May  3  2022 postgres_run
drwxr-xr-x  2  103 106 4.0K May  3  2022 redis_data

Apenas uma observação, algo ligeiramente diferente no meu caso.
A reconstrução ficou presa em O sistema de banco de dados está pronto para aceitar conexões, como outros já viram. Tive que reiniciar a VM e executar ./launcher start app para iniciar os Fóruns. No entanto, quando o Discourse voltou, a versão do Discourse permaneceu na versão anterior 3.3.0.beta4-dev.

Não consigo realizar a atualização do Ubuntu hoje, mas manterei todos informados quando puder e se a reconstrução for bem-sucedida.

Eu atualizei nossa instância de desenvolvimento para Ubuntu 20.6 hoje e a reconstrução/atualização foi bem-sucedida para o Discourse 3.4.0.beta2-dev. No entanto, este foi o host que também reconstruiu sem problemas no Ubuntu 18.4 ontem.