Tuve algunos problemas con la actualización: el primer foro falló en el primer intento (vía el panel de control) y luego falló nuevamente al intentar una reconstrucción, pero parece que funcionó en el segundo intento de reconstrucción, aunque luego tuve que realizar una reconstrucción adicional. Esto me recordó que debía detener todas las instancias de Discourse al realizar la actualización con la actualización de PG12 (hay tres foros de Discourse en este servidor, cada uno con su propio contenedor), y por lo tanto lo siguiente funcionó para los otros dos foros:
Sin embargo, por alguna razón, el primer foro ya no es accesible; Safari indica que el servidor interrumpió inesperadamente la conexión. Al realizar una reconstrucción parece ir bien, pero no es accesible y puedo entrar a la aplicación y a la consola de Rails, y la base de datos parece estar intacta.
Las únicas advertencias que puedo ver en la reconstrucción que podrían ser relevantes son:
168:M 31 ene 2021 21:39:22.459 # ADVERTENCIA: La configuración de TCP backlog de 511 no se puede aplicar porque /proc/sys/net/core/somaxconn está establecido en el valor inferior de 128.
168:M 31 ene 2021 21:39:22.459 # Servidor inicializado
168:M 31 ene 2021 21:39:22.459 # ADVERTENCIA: overcommit_memory está establecido en 0. El guardado en segundo plano podría fallar en condiciones de baja memoria. Para solucionar este problema, añade 'vm.overcommit_memory = 1' a /etc/sysctl.conf y luego reinicia o ejecuta el comando 'sysctl vm.overcommit_memory=1' para que surta efecto.
168:M 31 ene 2021 21:39:22.459 # ADVERTENCIA: tienes soporte para Transparent Huge Pages (THP) habilitado en tu kernel. Esto creará problemas de latencia y uso de memoria con Redis. Para solucionar este problema, ejecuta el comando 'echo madvise > /sys/kernel/mm/transparent_hugepage/enabled' como root y agrégalo a tu archivo /etc/rc.local para mantener la configuración después de un reinicio. Redis debe reiniciarse después de deshabilitar THP (establecer en 'madvise' o 'never').
168:M 31 ene 2021 21:39:22.459 * Cargando RDB generado por la versión 6.0.9
168:M 31 ene 2021 21:39:22.459 * Edad del RDB: 21 segundos
168:M 31 ene 2021 21:39:22.459 * Uso de memoria del RDB al crearse: 4.03 Mb
168:M 31 ene 2021 21:39:22.466 * Base de datos cargada desde el disco: 0.006 segundos
168:M 31 ene 2021 21:39:22.466 * Listo para aceptar conexiones
production.log:
Excepción del trabajo: Error al conectar con Redis en localhost:6379 (Errno::ENETUNREACH)
Error al conectar con Redis en localhost:6379 (Errno::ENETUNREACH) suscripción fallida, reconectando en 1 segundo. Pila de llamadas /var/www/discourse/vendor/bundle/ruby/2.7.0/gems/redis-4.2.5/lib/redis/client.rb:367:in `rescue in establish_connection'
Mensajes similares aparecen en unicorn.stderr.log y unicorn.stdout.log.
Al entrar al contenedor y ejecutar redis-cli ping, obtengo una respuesta PONG. Redis está ejecutándose en el servidor (pero no dentro de los contenedores individuales, aunque esto siempre ha sido así, por lo que sé).
¿Alguna idea de qué podría estar ocurriendo?
(También reinicié el servidor y creé un nuevo certificado letsencrypt para este dominio para estar seguro, pero sigue igual.)
Estoy bastante seguro de que no está relacionado con esto, ya que funcionaba perfectamente; esto solo ocurrió después de esa actualización/reconstrucción.