Errore 502 su nginx

Supporto Installazione
1

Ciao,

Ho appena eseguito ./launcher rebuild app senza errori apparenti. Ma quando provo ad aprire il sito, ricevo un errore 502.

Il log degli errori di nginx (shared/standalone/log/var-log/nginx/error.log) mostra:

2020/08/12 05:47:43 [error] 653#653: *7 connect() failed (111: Connection refused) while connecting to upstream, client: [...], server: _, request: "GET / HTTP/2.0", upstream: "http://127.0.0.1:3000/", host: "[...]"

Ho controllato tutti gli argomenti che ho trovato riguardo a errori 502 tra Discourse e nginx, ma non sono riuscito a trovare o comprendere nulla che abbia senso per il mio caso.

Questo potrebbe essere rilevante, eseguito dal container:

# netstat -plant
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 0.0.0.0:6379            0.0.0.0:*               LISTEN      -                   
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      644/nginx: master p 
tcp        0      0 0.0.0.0:5432            0.0.0.0:*               LISTEN      -                   
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      644/nginx: master p 
tcp6       0      0 :::6379                 :::*                    LISTEN      -                   
tcp6       0      0 :::5432                 :::*                    LISTEN      -

C’è qualcosa che dovrebbe essere in esecuzione sulla porta 3000?

Potresti indicarmi dove cercare ulteriori informazioni per risolvere questo problema?

Pura vida :slight_smile:

2

Inizialmente viene visualizzato il codice 502, poiché i servizi all’interno del container sono in fase di avvio. Dovrebbe scomparire entro 30 secondi. Se ciò non accade, è possibile che la CPU del tuo server sia sotto carico estremo, causando un rallentamento.

3

Grazie @itsbhanusharma.

Ho eseguito ./launcher restart app e monitorato il carico con top, ed è ben al di sotto del 10%.

Penso che la CPU sia sufficiente per gestire il carico:

$ cat /proc/cpuinfo  | grep 'name' | uniq
model name      : Intel(R) Xeon(R) CPU E5-1650 v3 @ 3.50GHz
$ cat /proc/cpuinfo  | grep process | wc -l
4

Esiste un modo migliore per eseguire il debug dell’avvio del contenitore?
Altre idee?

4

Quali plugin sono installati? Questo server è su SSD?

5

Ho appena clonato il repository ed eseguito i comandi di configurazione, quindi immagino abbia solo i plugin predefiniti? Non sono sicuro di dove verificare, ma sono certo di non averne aggiunti alcuno.

Il server non è SSD.

6

Ciao @elopio

Forse puoi pubblicare il tuo file ‘yml’ senza informazioni sensibili?

7

Certo, è qui:

8

Discourse richiede SSD; i normali dischi meccanici non forniscono IOPS sufficienti.

9

È questa la causa dell’errore 502? Oppure, senza un SSD, dovrei vedere il sito funzionante, ma molto lento?

10

Utilizzare un hard disk tradizionale invece di un SSD non dovrebbe causare un errore 502. Non è molto plausibile, come suggerisce la tua domanda, @elopio.

Ecco un breve articolo che potrebbe esserti utile:

A mio avviso, la cosa migliore da fare è aprire alcuni terminali ed eseguire tail -f sui file di log di Rails e nginx, inclusi i log degli errori e i log di accesso; quindi provare ad accedere e assicurarsi di tenere d’occhio le ultime righe dei file di log quando si verifica l’errore 502.

Sai dove risiedono questi file di log e come eseguire i comandi tail -f su di essi nei terminali?

Nota, avevi chiesto in precedenza:

Rails gira sulla porta 3000 all’interno del contenitore Docker e tale porta non è esposta all’esterno del contenitore. Ecco perché non vedi la porta 3000 all’esterno del contenitore quando esegui netstat fuori dal contenitore.

Spero sia utile.

11

Parlando per esperienza, un I/O lento può assolutamente causare timeout e un errore 502.

Gli IOPS a livello di SSD sono un requisito fondamentale.

12

Wooo, guardando i log di Rails ho scoperto che il log di Unicorn era enorme e segnalava alcuni errori di permessi. Ho eseguito rm -rf tmp/cache/bootsnap-compile-cache/ e ora vedo la schermata di congratulazioni!!!

Grazie amici. Ci giocherò un po’ prima di decidere se ricrearlo su un server SSD.

13

Di nulla @elopio

Sono contento che tu abbia individuato il problema nei log e che tu abbia risolto la situazione. Ottimo lavoro.

Ti auguro una navigazione serena!

14

Ok, sta funzionando in modo eccellente. Voglio mostrare cosa stiamo facendo:

https://bunqueer.jaquerespeis.org/

È la migrazione dello hackerspace costaricano da Telegram a Discourse :slight_smile: Dobbiamo ancora fare tantissime cose, ma questa volta sono sicuro che riusciremo finalmente a eliminare la chat. Grazie mille a tutti quelli di Discourse!