Errore di bootstrap - problema con pups

Ciao a tutti -

Recentemente ho cercato di ricostruire la nostra istanza di test dopo un aggiornamento senza successo. Cercare su Google/ChatGPT indica che forse c’è qualcosa che non va nella formattazione di app.yml, ma non sono riuscito a scoprirlo. Ecco l’output standard, che mi rendo conto non è molto utile:

x86_64 arch rilevato.
ATTENZIONE: il file containers/app.yml è leggibile da tutti. Puoi proteggere questo file eseguendo: chmod o-rwx containers/app.yml
Assicurazione che launcher sia aggiornato
La tua versione di Launcher è precedente all'origine
Arresto del vecchio container
app
2.0.20250226-0128: Pulling da discourse/base
Digest: sha256:6f18aa2cd22bba0deb91d69194e577d4f96130ad555ae8ec646a8792cbfe37db
Status: L'immagine è aggiornata a 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 si sta avviando oO0OoO0OoO0Oo
109:C 13 Jun 2025 15:20:04.997 # Versione Redis=7.0.15, bit=64, commit=00000000, modificato=0, pid=109, appena avviato
109:C 13 Jun 2025 15:20:04.997 # Configurazione caricata
109:M 13 Jun 2025 15:20:04.997 * orologio monotono: clock POSIX_gettime
109:M 13 Jun 2025 15:20:04.998 * Modalità di esecuzione=standalone, porta=6379.
109:M 13 Jun 2025 15:20:04.998 # Server inizializzato
109:M 13 Jun 2025 15:20:04.999 * Caricamento RDB prodotto dalla versione 7.0.7
109:M 13 Jun 2025 15:20:04.999 * Età RDB 14 secondi
109:M 13 Jun 2025 15:20:04.999 * Utilizzo memoria RDB al momento della creazione 2.95 Mb
109:M 13 Jun 2025 15:20:05.007 * Caricamento RDB completato, chiavi caricate: 3659, chiavi scadute: 0.
109:M 13 Jun 2025 15:20:05.007 * DB caricato dal disco: 0.008 secondi
109:M 13 Jun 2025 15:20:05.007 * Pronto per accettare connessioni
3649:C 13 Jun 2025 15:22:52.415 # oO0OoO0OoO0Oo Redis si sta avviando oO0OoO0OoO0Oo
3649:C 13 Jun 2025 15:22:52.415 # Versione Redis=7.0.15, bit=64, commit=00000000, modificato=0, pid=3649, appena avviato
3649:C 13 Jun 2025 15:22:52.415 # Configurazione caricata
3649:M 13 Jun 2025 15:22:52.415 * orologio monotono: clock POSIX_gettime
3649:M 13 Jun 2025 15:22:52.416 # Attenzione: Impossibile creare il socket di ascolto TCP del server *:6379: bind: Indirizzo già in uso
3649:M 13 Jun 2025 15:22:52.416 # Impossibile ascoltare sulla porta 6379 (TCP), interruzione.
109:M 13 Jun 2025 15:25:05.035 * 100 modifiche in 300 secondi. Salvataggio...
109:M 13 Jun 2025 15:25:05.041 * Salvataggio in background avviato dal pid 3823
3823:C 13 Jun 2025 15:25:05.257 * DB salvato su disco
3823:C 13 Jun 2025 15:25:05.257 * Fork CoW per RDB: corrente 1 MB, picco 1 MB, medio 0 MB
109:M 13 Jun 2025 15:25:05.342 * Salvataggio in background terminato con successo
109:signal-handler (1749828411) Ricevuto SIGTERM, pianificazione spegnimento...
109:M 13 Jun 2025 15:26:51.694 # Spegnimento richiesto dall'utente...
109:M 13 Jun 2025 15:26:51.694 * Salvataggio dello snapshot RDB finale prima dell'uscita.
109:M 13 Jun 2025 15:26:51.710 * DB salvato su disco
109:M 13 Jun 2025 15:26:51.710 # Redis è ora pronto per uscire, arrivederci...
bootstrap fallito con codice di uscita 1
** FALLITO IL BOOTSTRAP ** scorri verso l'alto e cerca messaggi di errore precedenti, potrebbero essercene più di uno.
./discourse-doctor può aiutare a diagnosticare il problema.
5b720b35a25e026d9908c60a2f7c5bcf3725b16a0b282875e8a66ce5ace4d06b

```Vorrei caricare lo stderr come allegato, ma come nuovo utente non posso. Forse quest'ultima parte del log con l'estratto che coinvolge pups è sufficiente?

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


C'è qualcos'altro che dovrei cercare che potrebbe fare luce sul problema? Apprezzo il tuo aiuto!

Tra l’altro, ho eseguito il file app.yml tramite un linter YAML e non ha trovato nulla. Ho anche provato a ricompilare senza plugin attivi e ciò non ha fatto differenza.

Suggerisco di incollare parte o tutto il tuo file YML - fai attenzione a censurare password e token di accesso. L’output

sembra sospetto. Il mio file YML è molto semplice, senza comandi, ma forse il tuo è complicato.

2 Mi Piace

Grazie @Ed_S. Ho allegato il YML nella speranza che ci sia un indizio lì.

app_yml_redacted.txt (4.7 KB)

Grazie. L’unica cosa che riesco a vedere è che dove io ho

templates/web.ratelimited.template.yml

tu hai

templates/web.ratelimited-whitelist.template.yml

Forse c’è un errore di sintassi in quel file? Sarebbe, credo, a

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

Anche se potrebbe esserci un errore di sintassi in uno qualsiasi degli altri template menzionati.

1 Mi Piace

Ho decisamente ristretto il campo a questo file:

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

che incollo qui sotto.

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;

C’è qualcosa nel comando run che sembra sbagliato?

La tua indentazione è solo leggermente diversa da quella che mi aspetterei. E hai una riga vuota alla fine. Ma non so se questi sono indizi.

1 Mi Piace

Al tuo posto inizierei a cancellare sezioni di questo YML con una ricerca binaria per trovare il colpevole. Hai un paio di righe vuote e hai due sezioni ‘replace’ che potresti forse rimuovere una alla volta. Inizia rimuovendo le sezioni principali e spera di riuscire a convergere sul problema.

2 Mi Piace

Grazie per il tuo aiuto @Ed_S, si è rivelato essere una cattiva indentazione nel file YAML che ho menzionato sopra. Non sono sicuro del perché nessuno dei linter l’abbia rilevato, ma confrontare il file problematico con uno in produzione ha reso subito chiaro il problema.

2 Mi Piace

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