Discourse Bad Gateway dopo il riavvio

Supporto Installazione
1

Il mio server è ospitato su una macchina virtuale fornita da uno dei principali provider cloud.
Ho installato con successo discourse e ha funzionato senza problemi per l’ultimo mese.
Oggi ho deciso di riportare le specifiche della mia VM alla configurazione originale (*) e di riavviarla. All’avvio, mentre tutto il resto sul server funziona correttamente, ottengo un errore 502 Bad Gateway quando provo ad accedere al forum Discourse. Pensando che l’istanza Docker non si fosse avviata automaticamente, mi sono connesso via SSH al server ed eseguito ./launcher start app, ma ho ricevuto un messaggio che indicava spazio insufficiente (5 GB disponibili); quindi ho eseguito df -h, che mi ha mostrato che in realtà ho 14 GB liberi. Ho quindi riprovato ./launcher start app, ma questa volta è apparso un avviso che Docker stava scaricando dei file e mi ha chiesto di attendere. Dopo qualche elaborazione, ho ricevuto il messaggio Nothing to do, your container has already started!. Tuttavia, i miei tentativi di accedere al forum hanno continuato a restituire 502 Bad Gateway.

Dopo aver consultato questo forum, ho deciso di eseguire ./launcher rebuild app e ho ottenuto i seguenti errori, relativi a PostgreSQL:

    user@host:[16:48]:/var/discourse# ./launcher rebuild app
    Ensuring launcher is up to date
    Fetching origin
    Launcher is up-to-date
    Stopping old container
    + /usr/bin/docker stop -t 60 app
    app
    cd /pups && git pull && /pups/bin/pups --stdin
    Already up to date.
    I, [2020-07-01T07:19:42.821347 #1]  INFO -- : Loading --stdin
    I, [2020-07-01T07:19:42.831806 #1]  INFO -- : > locale-gen $LANG && update-locale
    I, [2020-07-01T07:19:42.879007 #1]  INFO -- : Generating locales (this might take a while)...
    Generation complete.
    
    I, [2020-07-01T07:19:42.879431 #1]  INFO -- : > mkdir -p /shared/postgres_run
    I, [2020-07-01T07:19:42.885054 #1]  INFO -- :
    I, [2020-07-01T07:19:42.885734 #1]  INFO -- : > chown postgres:postgres /shared/postgres_run
    I, [2020-07-01T07:19:42.891657 #1]  INFO -- :
    I, [2020-07-01T07:19:42.892269 #1]  INFO -- : > chmod 775 /shared/postgres_run
    I, [2020-07-01T07:19:42.898103 #1]  INFO -- :
    I, [2020-07-01T07:19:42.898942 #1]  INFO -- : > rm -fr /var/run/postgresql
    I, [2020-07-01T07:19:42.905607 #1]  INFO -- :
    I, [2020-07-01T07:19:42.906463 #1]  INFO -- : > ln -s /shared/postgres_run /var/run/postgresql
    I, [2020-07-01T07:19:42.912617 #1]  INFO -- :
    I, [2020-07-01T07:19:42.913233 #1]  INFO -- : > socat /dev/null UNIX-CONNECT:/shared/postgres_run/.s.PGSQL.5432 || exit 0 && echo postgres already running stop container ; exit 1
    2020/07/01 07:19:42 socat[26] E connect(6, AF=1 "/shared/postgres_run/.s.PGSQL.5432", 36): No such file or directory
    I, [2020-07-01T07:19:42.925688 #1]  INFO -- :
    I, [2020-07-01T07:19:42.926081 #1]  INFO -- : > rm -fr /shared/postgres_run/.s*
    I, [2020-07-01T07:19:42.931174 #1]  INFO -- :
    I, [2020-07-01T07:19:42.931649 #1]  INFO -- : > rm -fr /shared/postgres_run/*.pid
    I, [2020-07-01T07:19:42.938154 #1]  INFO -- :
    I, [2020-07-01T07:19:42.938850 #1]  INFO -- : > mkdir -p /shared/postgres_run/12-main.pg_stat_tmp
    I, [2020-07-01T07:19:42.943575 #1]  INFO -- :
    I, [2020-07-01T07:19:42.944331 #1]  INFO -- : > chown postgres:postgres /shared/postgres_run/12-main.pg_stat_tmp
    I, [2020-07-01T07:19:42.949159 #1]  INFO -- :
    I, [2020-07-01T07:19:42.961190 #1]  INFO -- : File > /etc/service/postgres/run  chmod: +x  chown:
    I, [2020-07-01T07:19:42.973345 #1]  INFO -- : File > /etc/service/postgres/log/run  chmod: +x  chown:
    I, [2020-07-01T07:19:42.983929 #1]  INFO -- : File > /etc/runit/3.d/99-postgres  chmod: +x  chown:
    I, [2020-07-01T07:19:42.994843 #1]  INFO -- : File > /root/upgrade_postgres  chmod: +x  chown:
    I, [2020-07-01T07:19:42.995487 #1]  INFO -- : > chown -R root /var/lib/postgresql/12/main
    I, [2020-07-01T07:19:44.012812 #1]  INFO -- :
    I, [2020-07-01T07:19:44.013656 #1]  INFO -- : > [ ! -e /shared/postgres_data ] && install -d -m 0755 -o postgres -g postgres /shared/postgres_data && sudo -E -u postgres /usr/lib/postgresql/12/bin/initdb -D /shared/postgres_data || exit 0
    I, [2020-07-01T07:19:44.019545 #1]  INFO -- :
    I, [2020-07-01T07:19:44.019872 #1]  INFO -- : > chown -R postgres:postgres /shared/postgres_data
    I, [2020-07-01T07:19:44.064432 #1]  INFO -- :
    I, [2020-07-01T07:19:44.065186 #1]  INFO -- : > chown -R postgres:postgres /var/run/postgresql
    I, [2020-07-01T07:19:44.071385 #1]  INFO -- :
    I, [2020-07-01T07:19:44.072196 #1]  INFO -- : > /root/upgrade_postgres
    I, [2020-07-01T07:19:44.084004 #1]  INFO -- :
    I, [2020-07-01T07:19:44.084662 #1]  INFO -- : > rm /root/upgrade_postgres
    I, [2020-07-01T07:19:44.090399 #1]  INFO -- :
    I, [2020-07-01T07:19:44.092280 #1]  INFO -- : Replacing data_directory = '/var/lib/postgresql/12/main' with data_directory = '/shared/postgres_data' in /etc/postgresql/12/main/postgresql.conf
    I, [2020-07-01T07:19:44.093969 #1]  INFO -- : Replacing (?-mix:#?listen_addresses *=.*) with listen_addresses = '*' in /etc/postgresql/12/main/postgresql.conf
    I, [2020-07-01T07:19:44.095204 #1]  INFO -- : Replacing (?-mix:#?synchronous_commit *=.*) with synchronous_commit = $db_synchronous_commit in /etc/postgresql/12/main/postgresql.conf
    I, [2020-07-01T07:19:44.095937 #1]  INFO -- : Replacing (?-mix:#?shared_buffers *=.*) with shared_buffers = $db_shared_buffers in /etc/postgresql/12/main/postgresql.conf
    I, [2020-07-01T07:19:44.096695 #1]  INFO -- : Replacing (?-mix:#?work_mem *=.*) with work_mem = $db_work_mem in /etc/postgresql/12/main/postgresql.conf
    I, [2020-07-01T07:19:44.097554 #1]  INFO -- : Replacing (?-mix:#?default_text_search_config *=.*) with default_text_search_config = '$db_default_text_search_config' in /etc/postgresql/12/main/postgresql.conf
    I, [2020-07-01T07:19:44.101971 #1]  INFO -- : > install -d -m 0755 -o postgres -g postgres /shared/postgres_backup
    I, [2020-07-01T07:19:44.112672 #1]  INFO -- :
    I, [2020-07-01T07:19:44.113831 #1]  INFO -- : Replacing (?-mix:#?max_wal_senders *=.*) with max_wal_senders = $db_max_wal_senders in /etc/postgresql/12/main/postgresql.conf
    I, [2020-07-01T07:19:44.114973 #1]  INFO -- : Replacing (?-mix:#?wal_level *=.*) with wal_level = $db_wal_level in /etc/postgresql/12/main/postgresql.conf
    I, [2020-07-01T07:19:44.116047 #1]  INFO -- : Replacing (?-mix:#?checkpoint_segments *=.*) with checkpoint_segments = $db_checkpoint_segments in /etc/postgresql/12/main/postgresql.conf
    I, [2020-07-01T07:19:44.117033 #1]  INFO -- : Replacing (?-mix:#?logging_collector *=.*) with logging_collector = $db_logging_collector in /etc/postgresql/12/main/postgresql.conf
    I, [2020-07-01T07:19:44.118051 #1]  INFO -- : Replacing (?-mix:#?log_min_duration_statement *=.*) with log_min_duration_statement = $db_log_min_duration_statement in /etc/postgresql/12/main/postgresql.conf
    I, [2020-07-01T07:19:44.119352 #1]  INFO -- : Replacing (?-mix:^#local +replication +postgres +peer$) with local replication postgres  peer in /etc/postgresql/12/main/pg_hba.conf
    I, [2020-07-01T07:19:44.120299 #1]  INFO -- : Replacing (?-mix:^host.*all.*all.*127.*$) with host all all 0.0.0.0/0 md5 in /etc/postgresql/12/main/pg_hba.conf
    I, [2020-07-01T07:19:44.121038 #1]  INFO -- : > HOME=/var/lib/postgresql USER=postgres exec chpst -u postgres:postgres:ssl-cert -U postgres:postgres:ssl-cert /usr/lib/postgresql/12/bin/postmaster -D /etc/postgresql/12/main
    I, [2020-07-01T07:19:44.126334 #1]  INFO -- : > sleep 5
    2020-07-01 07:19:44.157 UTC [49] LOG:  starting PostgreSQL 12.2 (Debian 12.2-2.pgdg100+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.3.0-6) 8.3.0, 64-bit
    2020-07-01 07:19:44.158 UTC [49] LOG:  listening on IPv4 address "0.0.0.0", port 5432
    2020-07-01 07:19:44.158 UTC [49] LOG:  listening on IPv6 address "::", port 5432
    2020-07-01 07:19:44.161 UTC [49] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
    2020-07-01 07:19:44.162 UTC [49] FATAL:  could not map anonymous shared memory: Cannot allocate memory
    2020-07-01 07:19:44.162 UTC [49] HINT:  This error usually means that PostgreSQL's request for a shared memory segment exceeded available memory, swap space, or huge pages. To reduce the request size (currently 4423172096 bytes), reduce PostgreSQL's shared memory usage, perhaps by reducing shared_buffers or max_connections.
    2020-07-01 07:19:44.162 UTC [49] LOG:  database system is shut down
    I, [2020-07-01T07:19:49.141762 #1]  INFO -- :
    I, [2020-07-01T07:19:49.142221 #1]  INFO -- : > su postgres -c 'createdb discourse' || true
    createdb: error: could not connect to database template1: could not connect to server: No such file or directory
        Is the server running locally and accepting
        connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?
    I, [2020-07-01T07:19:49.227852 #1]  INFO -- :
    I, [2020-07-01T07:19:49.228226 #1]  INFO -- : > su postgres -c 'psql discourse -c "create user discourse;"' || true
    psql: error: could not connect to server: could not connect to server: No such file or directory
        Is the server running locally and accepting
        connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?
    I, [2020-07-01T07:19:49.330486 #1]  INFO -- :
    I, [2020-07-01T07:19:49.330822 #1]  INFO -- : > su postgres -c 'psql discourse -c "grant all privileges on database discourse to discourse;"' || true
    psql: error: could not connect to server: could not connect to server: No such file or directory
        Is the server running locally and accepting
        connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?
    I, [2020-07-01T07:19:49.425970 #1]  INFO -- :
    I, [2020-07-01T07:19:49.426356 #1]  INFO -- : > su postgres -c 'psql discourse -c "alter schema public owner to discourse;"'
    psql: error: could not connect to server: could not connect to server: No such file or directory
        Is the server running locally and accepting
        connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?
    I, [2020-07-01T07:19:49.506638 #1]  INFO -- :
    I, [2020-07-01T07:19:49.507202 #1]  INFO -- : Terminating async processes
    
    
    FAILED
    --------------------
    Pups::ExecError: su postgres -c 'psql discourse -c "alter schema public owner to discourse;"' failed with return #<Process::Status: pid 75 exit 2>
    Location of failure: /pups/lib/pups/exec_command.rb:112:in `spawn'
    exec failed with the params "su postgres -c 'psql $db_name -c \"alter schema public owner to $db_user;\"'"
    eb41679f76cd749ccd8c84a7543365d093619b80df6fc6750b9349fb63565fa1
    ** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
    ./discourse-doctor may help diagnose the problem.
    user@host:[17:19]:/var/discourse#

Stranamente, nonostante gli errori sopra riportati, l’esecuzione di ./launcher start app non produce errori:

starting up existing container
+ /usr/bin/docker start app
app

Con l’istanza in esecuzione, ho provato a usare ./launcher enter app per entrare nel contenitore. (Secondo la mia modesta opinione, gli strumenti disponibili nel contenitore sono molto limitati; sì, sono un utente nano e mi piace avere vari alias mappati; ad esempio ll). Non riesco a trovare il percorso fisico delle cartelle all’interno dell’istanza Docker (come vorrei fare per scaricarle tramite un client FTP).

In /var/log/nginx/error.log ho la seguente voce di errore ogni volta che aggiorno il browser:

2020/07/01 07:44:16 [error] 646#646: *3 connect() failed (111: Connection refused) while connecting to upstream, client: xxx.xx.0.1, server: _, request: "GET / HTTP/1.1", upstream: "http://127.0.0.1:3000/", host: "discourse.myDomain.com"

Qual potrebbe essere la causa del mio problema? Perché PostgreSQL improvvisamente non funziona più?

(*) Una settimana dopo l’installazione di Discourse, ho aggiornato il server con più CPU e memoria. Ho dovuto farlo per eseguire una videoconferenza che ho ospitato. Terminata la conferenza, sono tornato alla mia configurazione normale. Nota: non ho modificato le dimensioni del disco in nessun momento durante le modifiche alle specifiche.

2

Questo è dovuto al fatto che la tua attuale ricompilazione del contenitore non è riuscita; stai avviando una versione precedente della tua app. Questo è il comportamento normale. Quando una ricompilazione non ha successo, il contenitore originale non viene eliminato (in generale) e l’immagine originale rimane comunque disponibile.

Per quanto riguarda il tuo problema con PG, dovrai fornire al team maggiori dettagli sulla configurazione della tua app e del contenitore per ottenere il miglior supporto.

3

@neounix: Grazie.

Sono nuovo nell’hostare un forum Discourse, quindi non sono sicuro di dove guardare e cosa cercare. Ho un’installazione essenzialmente vanilla senza plugin o altre modifiche. Ho alcune variabili definite in app.yml e sto usando il mio demone Apache2 esistente come proxy inverso per inoltrare il traffico di Discourse, tramite un virtualhost separato, alla porta localhost su cui ho configurato Discourse in ascolto.
Potresti spiegare meglio quali informazioni sarebbero utili? Esiste una risorsa che potrei leggere per aiutarmi a risolvere il mio problema?

4

L’errore principale è presente nel file di log riportato sopra.

2020-07-01 07:19:44.162 UTC [49] FATAL:  impossibile mappare la memoria condivisa anonima: Impossibile allocare memoria

2020-07-01 07:19:44.162 UTC [49] HINT:  Questo errore indica solitamente che la richiesta di un segmento di memoria condivisa da parte di PostgreSQL ha superato la memoria disponibile, lo spazio di swap o le pagine grandi. Per ridurre la dimensione della richiesta (attualmente 4423172096 byte), riduci l'utilizzo della memoria condivisa di PostgreSQL, ad esempio diminuendo shared_buffers o max_connections.
5

Ho visto quell’errore, ma non ho apportato modifiche a app.yml.Dove posso ridurre shared_buffers o max_connections, dato che non sono presenti in app.yml? app.yml contiene solo il parametro db_shared_buffers, che è impostato sul valore predefinito “4096MB”, come è sempre stato (prima e dopo l’aumento della memoria del server).

6

Potresti considerare di pubblicare le tue statistiche relative alla memoria.

Ad esempio, su Linux:

$ free -m
              total        used        free      shared  buff/cache   available
Mem:          64299       12955        9678         361       41664       50265
Swap:          7807          69        7738

Per le statistiche di Docker, pubblica l’output di

docker stats

e così via.

L’errore è legato a una mancanza di memoria.

7

Le statistiche della memoria del server sono:

              total        used        free      shared  buff/cache   available
Mem:           3951        2236         414          86        1299        1308
Swap:           511         415          96

Statistiche della memoria dopo enter app:

              total        used        free      shared  buff/cache   available
Mem:           3951        2363         321          86        1266        1215
Swap:           511         415          96

L’esecuzione di docker stats > output.txt ha prodotto:

        CONTAINER ID        NAME                CPU %               MEM USAGE / LIMIT    MEM %               NET I/O             BLOCK I/O           PIDS
       ca4c5f37894c        app                 15.86%              6.48MiB / 3.859GiB   0.16%               20.3kB / 12.6kB     0B / 0B             25
        CONTAINER ID        NAME                CPU %               MEM USAGE / LIMIT    MEM %               NET I/O             BLOCK I/O           PIDS
       ca4c5f37894c        app                 15.86%              6.48MiB / 3.859GiB   0.16%               20.3kB / 12.6kB     0B / 0B             25
        CONTAINER ID        NAME                CPU %               MEM USAGE / LIMIT     MEM %               NET I/O             BLOCK I/O           PIDS
       ca4c5f37894c        app                 2.83%               6.539MiB / 3.859GiB   0.17%               20.3kB / 12.6kB     0B / 0B             25
        CONTAINER ID        NAME                CPU %               MEM USAGE / LIMIT     MEM %               NET I/O             BLOCK I/O           PIDS
       ca4c5f37894c        app                 2.83%               6.539MiB / 3.859GiB   0.17%               20.3kB / 12.6kB     0B / 0B             25
        CONTAINER ID        NAME                CPU %               MEM USAGE / LIMIT     MEM %               NET I/O             BLOCK I/O           PIDS
       ca4c5f37894c        app                 3.30%               6.477MiB / 3.859GiB   0.16%               20.3kB / 12.6kB     0B / 0B             25
        CONTAINER ID        NAME                CPU %               MEM USAGE / LIMIT     MEM %               NET I/O             BLOCK I/O           PIDS
       ca4c5f37894c        app                 3.30%               6.477MiB / 3.859GiB   0.16%               20.3kB / 12.6kB     0B / 0B             25
        CONTAINER ID        NAME                CPU %               MEM USAGE / LIMIT     MEM %               NET I/O             BLOCK I/O           PIDS
       ca4c5f37894c        app                 2.45%               6.535MiB / 3.859GiB   0.17%               20.3kB / 12.6kB     0B / 0B             25
        CONTAINER ID        NAME                CPU %               MEM USAGE / LIMIT     MEM %               NET I/O             BLOCK I/O           PIDS
       ca4c5f37894c        app                 2.45%               6.535MiB / 3.859GiB   0.17%               20.3kB / 12.6kB     0B / 0B             25
8

Ciao @nap

Puoi recuperare molta memoria fermando e poi rimuovendo tutti quei vecchi container app.

Ad esempio:

docker stop <container_id>
docker rm <container_id>

Assumendo che non siano in uso?

Se sono tutti in uso, allora dovresti considerare di aumentare la memoria di questo server oltre i 4 GB; forse puntare a 8 GB :slight_smile:

9

Ho fermato l’app con ./launcher stop app e poi ho rieseguito docker stats. Non erano elencati contenitori.
Sfortunatamente, aumentare la memoria significa pagare di più. La cosa più frustrante al momento è che funzionava lo scorso mese con 4GB.

10

E al momento non riesco nemmeno a ricostruire, il che non dovrebbe consumare molta memoria.

Con il contenitore non in esecuzione, le statistiche della memoria sono:

              total        used        free      shared  buff/cache   available
Mem:           3951        2207         169          91        1574        1332
Swap:           511         446          65

Ho alcune cartelle interessanti in ./var/lib/docker/overlay2/:

e3e6cdfcc62c2e0b68ec91efxxxxx6c69212c95b5070f7b6b84e97edcb473ea2
64a04d1b97a18f51a5fdc536xxxxxf9473de0c2ccd1a2cc0d62e830164b5f2d8
355303c6af7bebff1163195c5xxxxx8fd1de6333e39adbcb573c7365673b6c85

Posso cancellarle?

11

Giusto.

Capisco. Ero impegnato a lavorare su un’altra attività e non ho notato che il tuo output mostrava le statistiche per lo stesso contenitore e non per più contenitori.

Cosa ti dice free -m ora che il tuo contenitore non è in esecuzione?

Penso che 4 GB di RAM siano sufficienti per un singolo contenitore, di sicuro.

12

No.

Non cancellare quei file docker.

Il problema, dal messaggio di errore, è legato alla tua configurazione PG 12 di Discourse. Non sono sicuro di come affrontarlo, perché modificare il file di configurazione PG 12 per Discourse non è supportato, credo.

I “top gun” di Meta avranno suggerimenti migliori dei miei, specialmente i team professionali di hosting.

13

Quindi stai dicendo che questo è interno ai file all’interno della configurazione Docker? E modificarlo manualmente causerà problemi non appena il contenitore viene avviato o aggiornato?

14

@nap

Se cerchi su Google il messaggio di errore sopra (tra virgolette), troverai diverse discussioni direttamente pertinenti su questo esatto messaggio di errore di PostgreSQL.

Spero che questo ti sia d’aiuto.

15

Dopo aver fatto ciò, hai eseguito di nuovo ./discourse-setup o modificato a mano le impostazioni di memoria nel file app.yml? Cosa sono db_shared_buffers, unicorn_workers e db_work_mem?

Tranne il fatto che stai utilizzando un reverse proxy, il che complica le cose. Non è chiaro che il reverse proxy sia la causa del problema, ma rende comunque la situazione più complessa.

Hai più partizioni? Potrebbe essere che la partizione in cui Docker crea le immagini sia piena?

16

@pfaffman : Grazie per aver dato un’occhiata.

No, ho solo aggiunto una serie di definizioni di variabili relative al nome del sito e all’uso dei tag.

db_shared_buffers è “4096MB”
unicorn_workers è 8
db_work_mem è commentato

Ho una partizione principale da 40G (14GB liberi), 512MB di swap e una partizione da 8GB per i backup (non montata).

Sembra che abbia superato il problema. Inizialmente ho provato a ridurre i buffer a 2GB e i worker a 4, ma ho ottenuto lo stesso errore. Poi ho ridotto i buffer a 1GB, momento in cui rebuild è andato a buon fine e il forum è di nuovo online.

Grazie a tutti!!