502 Bad Gateway después de reconstrucción online de Producción tests-passed

Soporte Instalación
1

Reiniciar el servidor, reiniciar el contenedor, la reconstrucción de la consola no ayudan.

El contenedor está activo ya que puedo usar ./launcher enter app

Tengo un montón de estos en los registros, ¿ideas sobre cómo investigar el fallo de redis?

Error conectando a Redis en localhost:6379 (Errno::EADDRNOTAVAIL) subscribe failed, reconectando en 1 segundo. Pila de llamadas /var/www/discourse/vendor/bundle/ruby/3.2.0/gems/redis-4.8.1/lib/redis/client.rb:398:in `rescue in establish_connection'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/redis-4.8.1/lib/redis/client.rb:379:in `establish_connection'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/redis-4.8.1/lib/redis/client.rb:115:in `block in connect'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/redis-4.8.1/lib/redis/client.rb:344:in `with_reconnect'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/redis-4.8.1/lib/redis/client.rb:114:in `connect'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/redis-4.8.1/lib/redis/client.rb:409:in `ensure_connected'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/redis-4.8.1/lib/redis/client.rb:269:in `block in process'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/redis-4.8.1/lib/redis/client.rb:356:in `logging'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/redis-4.8.1/lib/redis/client.rb:268:in `process'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/redis-4.8.1/lib/redis/client.rb:161:in `call'first?

No estoy seguro de si esto es una buena idea, pero intenté iniciarlo manualmente:

/var/www/discourse# redis-server
3770:C 14 Dec 2023 17:20:17.171 # oO0OoO0OoO0Oo Redis está iniciando oO0OoO0OoO0Oo
3770:C 14 Dec 2023 17:20:17.171 # Versión de Redis=7.0.7, bits=64, commit=00000000, modificado=0, pid=3770, recién iniciado
3770:C 14 Dec 2023 17:20:17.171 # Advertencia: no se especificó ningún archivo de configuración, se usa la configuración predeterminada. Para especificar un archivo de configuración, use redis-server /ruta/a/redis.conf
3770:M 14 Dec 2023 17:20:17.173 * reloj monotónico: POSIX clock_gettime
3770:M 14 Dec 2023 17:20:17.173 # Advertencia: No se pudo crear el socket de escucha TCP del servidor *:6379: bind: Dirección ya en uso
3770:M 14 Dec 2023 17:20:17.173 # Falló la escucha en el puerto 6379 (TCP), abortando.
2

¿Redis se está ejecutando realmente dentro del contenedor?

¿sv cree que sí?

root@michael-discourse-docker-app:/# sv status redis
run: redis: (pid 548) 9843135s; run: log: (pid 547) 9843135s

¿Aparece algo en /var/log/redis/current?

¿Puedes ejecutar sv down redis (si está activo) y sv up redis?

¿Aparecen registros relevantes después de eso?

3 
/var/www/discourse/log# sv status redis
run: redis: (pid 565) 1430s; run: log: (pid 560) 1430s

/var/www/discourse/log# sv down redis
/var/www/discourse/log# sv up redis
/var/www/discourse/log# tail /var/log/redis/current
4766:M 14 Dec 2023 17:26:20.195 * Reloj monótono: POSIX clock_gettime
4766:M 14 Dec 2023 17:26:20.195 * Running mode=standalone, port=6379.
4766:M 14 Dec 2023 17:26:20.195 # Server initialized
4766:M 14 Dec 2023 17:26:20.195 # ADVERTENCIA: El overcommit de memoria debe estar habilitado. Sin él, una copia de seguridad en segundo plano o la replicación pueden fallar en condiciones de poca memoria. Al estar deshabilitado, también puede causar fallos sin condiciones de poca memoria, véase https://github.com/jemalloc/jemalloc/issues/1328. Para solucionar este problema, añada 'vm.overcommit_memory = 1' a /etc/sysctl.conf y luego reinicie o ejecute el comando 'sysctl vm.overcommit_memory=1' para que esto tenga efecto.
4766:M 14 Dec 2023 17:26:20.196 * Cargando RDB producido por la versión 7.0.7
4766:M 14 Dec 2023 17:26:20.196 * Edad de RDB 3 segundos
4766:M 14 Dec 2023 17:26:20.196 * Uso de memoria de RDB cuando se creó 24.56 Mb
4766:M 14 Dec 2023 17:26:20.317 * Carga de RDB completada, claves cargadas: 21165, claves expiradas: 3.
4766:M 14 Dec 2023 17:26:20.317 * DB cargada desde disco: 0.121 segundos
4766:M 14 Dec 2023 17:26:20.317 * Listo para aceptar conexiones
4

¡Encontré el problema! ¡Un plugin! (¡el mío!)

5

Gracias Michael, ¡parece que fue una infracción de nomenclatura de Zeitwerk! (que Rubocop no detectó, y funciona en desarrollo).

¡Pero esos comandos son muy, muy útiles como referencia futura!