Cómo rastrear el fallo de discourse upstream dentro del container que resulta en 502 Bad Gateway

(Sí, busqué primero)

Después de usar recientemente la interfaz de actualización de administrador, mi instancia de Discourse dejó de funcionar, respondiendo con 502 Bad Gateway.

He entrado en el contenedor y parece que está ejecutando un nginx que espera un servidor en localhost:3000, el cual no se está ejecutando.

(54) Esperando que los nuevos workers de unicorn bajo 3802725 se inicien...
(54) Esperando que los nuevos workers de unicorn bajo 3802725 se inicien...
(54) El PID anterior es: 3800363 El PID nuevo es: 3802725
config/unicorn_launcher: line 71: kill: (3802725) - No such process
config/unicorn_launcher: line 15: kill: (3802725) - No such process
(54) saliendo
ok: run: redis: (pid 62) 3418739s
ok: run: postgres: (pid 53) 3418739s
supervisor pid: 3803896 unicorn pid: 3803900
config/unicorn_launcher: line 71: kill: (3803900) - No such process
config/unicorn_launcher: line 15: kill: (3803900) - No such process
(3803896) saliendo

esto es seguido repetidamente por:

ok: run: redis: (pid 64) 4905s
ok: run: postgres: (pid 65) 4905s
supervisor pid: 18571 unicorn pid: 18575
config/unicorn_launcher: line 71: kill: (18575) - No such process
config/unicorn_launcher: line 15: kill: (18575) - No such process
(18571) saliendo

Me gustaría iniciar este hilo para obtener ayuda en la depuración de esto; ¿cuál es el siguiente paso aquí, qué comando está intentando ejecutar Discourse? (Sé que podría averiguarlo leyendo/haciendo ingeniería inversa del código, pero puede ser útil tener un hilo sobre esto en el foro).

Agradecería cualquier indicación.

1 me gusta

Empieza buscando :wink:

¿Esto se parece?

¿Estás usando una instalación estándar totalmente estándar?

Dada la fecha, lo más probable es que esté relacionado con un cambio en el explorador de datos que causó algunos problemas. Lo hemos revertido, así que si vuelves a intentar la reconstrucción, debería funcionar mejor

3 Me gusta

Sí, estoy usando el explorador de datos. No hice un git pull antes de reiniciar.
Cuando hago un git pull, y luego ./launcher restart app no se soluciona.

Excepto que lo estoy ejecutando detrás de un nginx en el host.
(Y tengo algunos complementos, como el explorador de datos).

Ahora estoy intentando ./launcher rebuild app - espero que reconstruir la aplicación preserve la base de datos de mi foro… y que no termine con mi foro reiniciado.
Hacer launcher rebuild app no soluciona el problema.

Esta publicación describe un problema con contenedores privilegiados vs. no privilegiados, pero no proporciona más información. También es de hace 2 años, por lo que puede no estar relacionado con una actualización reciente.

Claro, la base de datos está en la carpeta compartida montada, así que persiste.

Reiniciar el contenedor después de un git pull probablemente no será suficiente.

Entendido. Yo también ejecuto ./launcher rebuild app. ¿Eso no actualizaría los plugins?

Sí, eso también actualizará los plugins (siempre que se clonen dentro de app.yml)

En caso de que esto todavía se esté investigando, tuve un error de puerta de enlace 502, pero no directamente después de que la rutina de actualización fallara a mitad de camino con un error de versión de Ruby. Como no había actualizado el servidor en unas seis semanas, ejecuté apt update/upgrade y reinicié. Fue entonces cuando ocurrió el error 502, no pude poner en marcha el sitio web del foro. Reconstruir la aplicación solucionó las cosas y también actualizó Discourse por completo.

A modo de registro, tengo estos complementos instalados y habilitados:

discourse-bbcode
discourse-data-explorer
discourse-docs
docker_manager
styleguide

y estos instalados pero deshabilitados:

discourse-topic-list-previews
discoursepage

4 publicaciones se dividieron en un nuevo tema: ¿Hay un diagnóstico paso a paso para cuando se encuentra un sitio de Discourse con un error 502 Bad Gateway?