Falha ao inicializar erro - problema com pups

Instalação
1

Olá pessoal -

Recentemente, tenho tentado reconstruir nossa instância de teste após uma atualização sem sucesso. Pesquisar no Google/ChatGPT indica que talvez algo esteja errado com a formatação do app.yml, mas não consegui descobrir. Aqui está o stdout, que percebo que não é muito útil:

x86_64 arch detectado.
AVISO: containers/app.yml file is world-readable. You can secure this file by running: chmod o-rwx containers/app.yml
Garantindo que o launcher esteja atualizado
Sua versão do Launcher está à frente da origem
Parando o contêiner antigo
app
2.0.20250226-0128: Puxando de discourse/base
Digest: sha256:6f18aa2cd22bba0deb91d69194e577d4f96130ad555ae8ec646a8792cbfe37db
Status: Imagem está atualizada para discourse/base:2.0.20250226-0128
docker.io/discourse/base:2.0.20250226-0128
/usr/local/lib/ruby/gems/3.3.0/gems/pups-1.2.1/lib/pups.rb
/usr/local/bin/pups --stdin
109:C 13 Jun 2025 15:20:04.997 # oO0OoO0OoO0Oo Redis está iniciando oO0OoO0OoO0Oo
109:C 13 Jun 2025 15:20:04.997 # Redis version=7.0.15, bits=64, commit=00000000, modified=0, pid=109, acabou de iniciar
109:C 13 Jun 2025 15:20:04.997 # Configuração carregada
109:M 13 Jun 2025 15:20:04.997 * Relógio monotônico: POSIX clock_gettime
109:M 13 Jun 2025 15:20:04.998 * Modo de execução=standalone, porta=6379.
109:M 13 Jun 2025 15:20:04.998 # Servidor inicializado
109:M 13 Jun 2025 15:20:04.999 * Carregando RDB produzido pela versão 7.0.7
109:M 13 Jun 2025 15:20:04.999 * Idade do RDB 14 segundos
109:M 13 Jun 2025 15:20:04.999 * Uso de memória do RDB quando criado 2.95 Mb
109:M 13 Jun 2025 15:20:05.007 * Concluído o carregamento do RDB, chaves carregadas: 3659, chaves expiradas: 0.
109:M 13 Jun 2025 15:20:05.007 * DB carregado do disco: 0.008 segundos
109:M 13 Jun 2025 15:20:05.007 * Pronto para aceitar conexões
3649:C 13 Jun 2025 15:22:52.415 # oO0OoO0OoO0Oo Redis está iniciando oO0OoO0OoO0Oo
3649:C 13 Jun 2025 15:22:52.415 # Redis version=7.0.15, bits=64, commit=00000000, modified=0, pid=3649, acabou de iniciar
3649:C 13 Jun 2025 15:22:52.415 # Configuração carregada
3649:M 13 Jun 2025 15:22:52.415 * Relógio monotônico: POSIX clock_gettime
3649:M 13 Jun 2025 15:22:52.416 # Aviso: Não foi possível criar o socket de escuta TCP do servidor *:6379: bind: Endereço já em uso
3649:M 13 Jun 2025 15:22:52.416 # Falha ao escutar na porta 6379 (TCP), abortando.
109:M 13 Jun 2025 15:25:05.035 * 100 alterações em 300 segundos. Salvando...
109:M 13 Jun 2025 15:25:05.041 * Salvamento em segundo plano iniciado pelo pid 3823
3823:C 13 Jun 2025 15:25:05.257 * DB salvo em disco
3823:C 13 Jun 2025 15:25:05.257 * Fork CoW para RDB: atual 1 MB, pico 1 MB, média 0 MB
109:M 13 Jun 2025 15:25:05.342 * Salvamento em segundo plano concluído com sucesso
109:signal-handler (1749828411) SIGTERM recebido, agendando desligamento...
109:M 13 Jun 2025 15:26:51.694 # Desligamento solicitado pelo usuário...
109:M 13 Jun 2025 15:26:51.694 * Salvando o snapshot RDB final antes de sair.
109:M 13 Jun 2025 15:26:51.710 * DB salvo em disco
109:M 13 Jun 2025 15:26:51.710 # Redis está pronto para sair, tchau...
bootstrap falhou com código de saída 1
** FALHA AO INICIAR ** por favor, role para cima e procure por mensagens de erro anteriores, pode haver mais de uma.
./discourse-doctor pode ajudar a diagnosticar o problema.
5b720b35a25e026d9908c60a2f7c5bcf3725b16a0b282875e8a66ce5ace4d06b

```Gostaria de enviar o stderr como anexo, mas como sou um novo usuário, não consigo. Talvez este último trecho do log com o trecho envolvendo pups seja suficiente?

2025-06-13 15:26:51.615 UTC [42] LOG: aborting any active transactions
2025-06-13 15:26:51.634 UTC [42] LOG: background worker “logical replication launcher” (PID 56) exited with exit code 1
2025-06-13 15:26:51.634 UTC [51] LOG: shutting down
2025-06-13 15:26:51.637 UTC [51] LOG: checkpoint starting: shutdown immediate
2025-06-13 15:26:51.646 UTC [51] LOG: checkpoint complete: wrote 15 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.001 s, sync=0.003 s, total=0.012 s; sync files=3, longest=0.003 s, average=0.001 s; distance=49 kB, estimate=243 kB
2025-06-13 15:26:51.659 UTC [42] LOG: database system is shut down
/usr/local/lib/ruby/gems/3.3.0/gems/pups-1.2.1/lib/pups/config.rb:223:in block (2 levels) in run_commands': Invalid run command filename (SyntaxError) from /usr/local/lib/ruby/gems/3.3.0/gems/pups-1.2.1/lib/pups/config.rb:211:in each’
from /usr/local/lib/ruby/gems/3.3.0/gems/pups-1.2.1/lib/pups/config.rb:211:in block in run_commands' from /usr/local/lib/ruby/gems/3.3.0/gems/pups-1.2.1/lib/pups/config.rb:210:in each’
from /usr/local/lib/ruby/gems/3.3.0/gems/pups-1.2.1/lib/pups/config.rb:210:in run_commands' from /usr/local/lib/ruby/gems/3.3.0/gems/pups-1.2.1/lib/pups/config.rb:191:in run’
from /usr/local/lib/ruby/gems/3.3.0/gems/pups-1.2.1/lib/pups/cli.rb:89:in run' from /usr/local/lib/ruby/gems/3.3.0/gems/pups-1.2.1/bin/pups:9:in
from /usr/local/bin/pups:25:in load' from /usr/local/bin/pups:25:in ’


Há mais alguma coisa que eu deveria procurar que pudesse esclarecer o problema? Agradeço a sua ajuda!
2

A propósito, executei o arquivo app.yml através de um linter YAML e ele não encontrou nada. Também tentei reconstruir sem nenhum plugin ativo, e isso não fez diferença.

3

Sugiro que cole parte ou todo o seu arquivo YML - tome cuidado para redigir senhas e tokens de acesso. A saída

parece suspeita. Meu próprio arquivo YML é muito simples, sem comandos, mas talvez o seu seja complicado.

2 curtidas
4

Obrigado @Ed_S. Anexei o YML na esperança de que haja uma pista lá.

app_yml_redacted.txt (4.7 KB)

5

Obrigado. A única coisa que consigo ver é que onde eu tenho

templates/web.ratelimited.template.yml
você tem
templates/web.ratelimited-whitelist.template.yml
É possível que haja um erro de sintaxe nesse arquivo? Seria, eu acho, em
/var/discourse/templates/web.ratelimited-whitelist.template.yml
Embora possa haver igualmente um erro de sintaxe em qualquer um dos outros modelos mencionados.

1 curtida
6

Eu definitivamente reduzi para este arquivo:

/var/discourse/templates/web.ratelimited-whitelist.template.yml

que estou colando abaixo.

params:
  reqs_per_second: 12
  burst_per_second: 12
  reqs_per_minute: 200
  burst_per_minute: 100
  conn_per_ip: 20

run:
  - replace:
    filename: "/etc/nginx/conf.d/discourse.conf"
    from: /server.+{/
    to: |
       geo $limit {
           default 1;
           XX.YYY.ZZ.ZZZ 0; # hubprod
           XXX.YY.ZZZ.ZZZ 0; # hubdev
       }

       map $limit $limit_key {
           0 "";
           1 $binary_remote_addr;
       }

       limit_req_zone $limit_key zone=flood:10m rate=$reqs_per_secondr/s;
       limit_req_zone $limit_key zone=bot:10m rate=$reqs_per_minuter/m;
       limit_req_status 429;
       limit_conn_zone $limit_key zone=connperip:10m;
       limit_conn_status 429;
       server {
  - replace:
    filename: "/etc/nginx/conf.d/discourse.conf"
    from: "/location @discourse {/"
    to: |
       location @discourse {
         limit_conn connperip $conn_per_ip;
         limit_req zone=flood burst=$burst_per_second nodelay;
         limit_req zone=bot burst=$burst_per_minute nodelay;

Há algo no comando run que pareça errado?

7

Sua indentação é apenas ligeiramente diferente do que eu poderia esperar. E você tem uma linha em branco no final. Mas não sei se são pistas.

1 curtida
8

Eu acho que no seu lugar eu começaria a deletar seções deste YML em uma busca binária para encontrar o culpado. Você tem algumas linhas em branco e duas seções de ‘replace’ que você poderia talvez remover uma de cada vez. Comece removendo seções principais e espere que você consiga convergir para o problema.

2 curtidas
9

Obrigado pela ajuda @Ed_S, acabou sendo uma má indentação no arquivo YAML que mencionei acima. Não tenho certeza por que nenhum dos linters detectou isso, mas comparar o arquivo problemático com um em produção deixou o problema claro imediatamente.

2 curtidas
10

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.