Discourse Bad Gateway tras reinicio

Soporte Instalación
1

My server runs on in a Virtual Machine hosted by one of the major cloud providers.
I successfully installed discourse on it and it’s been running fine for the last month.
Today, I decided to change the specifications of my VM back to its original configuration(*) and rebooted. Upon startup, whilst everything else on my server is running fine, I’m getting a 502 Bad Gateway error when I attempt to access the discourse forum. Thinking the docker instance had not automatically started up, I SSHed into my server and ran ./launcher start app but got a message saying I had insufficient space remaining (5GB available), so I ran df -h which tells me I actually have 14GB available. So I ran ./launcher start app again, but this time I got a warning that docker was going to download stuff and to be patient. After some processing, I got the message Nothing to do, your container has already started!. However, my attempts to access the forum still returned 502 Bad Gateway.
After consulting this forum here, I decided to run ./launcher rebuild app and got the following errors, something to do with 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.891655 #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.938152 #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#

Strangely, in spite of the errors above, running ./launcher start app produces no errors:

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

With the instance running, I tried using ./launcher enter app to get into the container. (In my humble opinion the available tools in the container are very poor (yes I’m a nano user and like to have various aliases mapped; e.g. ll). I’m not able to find the physical path to the folders within the docker instance (as I would like to download them using a FTP client).

In /var/log/nginx/error.log I have the following error entry for each time I refresh my 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"

What could be the cause of my problem? Why is Postgre suddenly not functioning?

(*) A week after installing Discourse, I upgraded my server with more CPUs and memory. I needed to do this to run a video conference I hosted. With the conference done, I’ve gone back to my normal configuration. Note that I did not change the disk sizes at any point during the specification changes.

1 me gusta
2

Esto se debe a que tu reconstrucción actual del contenedor falló y estás iniciando una versión anterior de tu app. Este es el comportamiento normal. Cuando una reconstrucción no tiene éxito, el contenedor original no se elimina (en términos generales) y la imagen original también sigue disponible.

En cuanto a tu problema con PG, necesitarás proporcionar al equipo más detalles sobre tu aplicación y la configuración del contenedor para obtener el mejor soporte.

2 Me gusta
3

@neounix: Gracias.

Soy nuevo en la administración de un foro de Discourse, así que no estoy seguro de dónde buscar ni en qué fijarme. Tengo una instalación esencialmente estándar, sin plugins ni otras modificaciones. He definido algunas variables en app.yml y estoy utilizando mi servicio Apache2 existente como proxy inverso para redirigir el tráfico de Discourse, a través de un host virtual separado, al puerto de localhost en el que he configurado Discourse para escuchar.

¿Podrías ampliar qué información sería útil? ¿Existe algún recurso que pueda leer para ayudarme a depurar mi situación?

4

El error principal se encuentra en el archivo de registro mostrado arriba.

2020-07-01 07:19:44.162 UTC [49] FATAL:  no se pudo mapear memoria compartida anónima: No se puede asignar memoria

2020-07-01 07:19:44.162 UTC [49] HINT:  Este error generalmente significa que la solicitud de PostgreSQL para un segmento de memoria compartida superó la memoria disponible, el espacio de intercambio o las páginas grandes. Para reducir el tamaño de la solicitud (actualmente 4423172096 bytes), reduzca el uso de memoria compartida de PostgreSQL, quizás reduciendo shared_buffers o max_connections.
2 Me gusta
5

Vi ese error, pero no he realizado ningún cambio en app.yml.
¿Dónde puedo reducir shared_buffers o max_connections, si no están en app.yml? app.yml solo tiene un parámetro db_shared_buffers, pero está configurado con el valor predeterminado “4096MB”, como siempre ha estado (antes y después de aumentar la memoria del servidor).

6

Podrías considerar publicar tus estadísticas relacionadas con la memoria.

Por ejemplo, en Linux:

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

y para las estadísticas de Docker, publica la salida de

docker stats

etc.

El error está relacionado con la falta de memoria.

2 Me gusta
7

Las estadísticas de memoria del servidor son:

              total        usada        libre      compartida  buff/cache   disponible
Mem:           3951        2236         414          86        1299        1308
Swap:           511         415          96

Estadísticas de memoria después de enter app:

              total        usada        libre      compartida  buff/cache   disponible
Mem:           3951        2363         321          86        1266        1215
Swap:           511         415          96

Ejecutar docker stats > output.txt produjo:

        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
2 Me gusta
8

Hola @nap

Puedes recuperar mucha memoria deteniendo y luego eliminando todos esos contenedores antiguos de app.

Por ejemplo:

docker stop <container_id>
docker rm <container_id>

¿Asumiendo que no están en uso?

Si todos están en uso, entonces deberías considerar aumentar la memoria de este servidor por encima de 4 GB; quizás optar por 8 GB :slight_smile:

3 Me gusta
9

Detuve la aplicación con ./launcher stop app y luego volví a ejecutar docker stats. No se listaron contenedores.

Lamentablemente, aumentar la memoria implica pagar más. Lo más frustrante en este momento es que el mes pasado funcionaba con 4 GB.

1 me gusta
10

Y ni siquiera puedo reconstruir en este momento, lo cual no debería consumir tanta memoria.

Sin el contenedor en ejecución, las estadísticas de memoria son:

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

Tengo algunos directorios interesantes en ./var/lib/docker/overlay2/:

e3e6cdfcc62c2e0b68ec91efxxxxx6c69212c95b5070f7b6b84e97edcb473ea2
64a04d1b97a18f51a5fdc536xxxxxf9473de0c2ccd1a2cc0d62e830164b5f2d8
355303c6af7bebff1163195c5xxxxx8fd1de6333e39adbcb573c7365673b6c85

¿Puedo eliminarlos?

11

Correcto.

Entiendo. Estaba ocupado trabajando en otra tarea y no noté que tu salida mostraba las estadísticas del mismo contenedor y no de varios.

¿Qué te dice ahora free -m con tu contenedor detenido?

Creo que los 4 GB de RAM están bien para un solo contenedor, sin duda.

12

No.

No elimines esos archivos de Docker.

El problema, según el mensaje de error, está relacionado con tu configuración de Discourse PG 12. No estoy seguro de cómo abordarlo, ya que creo que no se admite ajustar el archivo de configuración de PG 12 para Discourse.

Los expertos de meta tendrán mejores sugerencias que yo, especialmente los equipos de alojamiento profesional.

2 Me gusta
13

¿Lo que estás diciendo es que esto es interno a los archivos dentro de la configuración de Docker? ¿Y que modificarlo manualmente causará problemas una vez que el contenedor se inicie o se actualice?

14

@nap

Si buscas en Google el mensaje de error anterior (entre comillas), encontrarás varias discusiones directamente relevantes sobre este mensaje de error exacto de PostgreSQL.

Espero que esto ayude.

3 Me gusta
15

¿Después de hacer eso, volviste a ejecutar ./discourse-setup o modificaste a mano la configuración de memoria en app.yml? ¿Qué son db_shared_buffers, unicorn_workers y db_work_mem?

Excepto que estás ejecutando detrás de un proxy inverso, lo que complica las cosas. No está claro que el proxy inverso sea el culpable aquí, pero sí complica las cosas.

¿Tienes múltiples particiones? ¿Podría ser que la partición donde Docker crea las imágenes esté llena?

5 Me gusta
16

@pfaffman: Gracias por echar un vistazo.

No, lo único que hice fue agregar una serie de definiciones de variables relacionadas con el nombre del sitio y el uso de etiquetas.

db_shared_buffers es “4096MB”
unicorn_workers es 8
db_work_mem está comentado

Tengo una partición principal de 40G (14GB libres), 512MB de swap y una partición de 8GB para copias de seguridad (no montada).

Parece que he superado el problema. Inicialmente intenté reducir los buffers a 2GB y los workers a 4, pero obtuve el mismo error. Luego reduje los buffers a 1GB, momento en el cual rebuild tuvo éxito y el foro ya está de nuevo en línea.

¡Gracias a todos!

3 Me gusta
17

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