El foro no está disponible debido a un error de Redis en los registros de unicorn

Hola.

Estoy alojando dos foros en mi máquina, ambos están actualizados (3.4.0.beta3-dev para uno, y no puedo comprobar el que no está disponible).

Uno de ellos se actualizó a principios de esta semana y dejó de funcionar de repente hace unos 2 días.

Una vez que inicio sesión, aparece un mensaje de “Oops” en cada página.

Entré en el contenedor y miré los registros de unicorn y parece haber un problema al conectarse con redis:

Failed to report error: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) 3 Error fetching job: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED)
Failed to report error: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) 3 Error fetching job: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED)
Failed to report error: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) 3 Error fetching job: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED)
Failed to report error: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) 3 Error fetching job: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED)
Failed to report error: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) 3 Job exception: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) sidekiq-exception
Failed to report error: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) 3 Job exception: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) sidekiq-exception
Failed to report error: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) 3 Job exception: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) sidekiq-exception
Failed to report error: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) 3 Job exception: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) sidekiq-exception
Failed to report error: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) 3 Job exception: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) sidekiq-exception
Failed to report error: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) 3 Job exception: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) sidekiq-exception
Failed to report error: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) 2 Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) subscribe failed, reconnecting in 1 second. Call stack /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:398:in `rescue in establish_connection'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:379:in `establish_connection'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:115:in `block in connect'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:344:in `with_reconnect'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:114:in `connect'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:409:in `ensure_connected'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:269:in `block in process'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:356:in `logging'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:268:in `process'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:161:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rack-mini-profiler-3.3.1/lib/mini_profiler/profiling_methods.rb:89:in `block in profile_method'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis.rb:270:in `block in send_command'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis.rb:269:in `synchronize'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis.rb:269:in `send_command'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/commands/strings.rb:191:in `get'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/message_bus-4.3.8/lib/message_bus/backends/redis.rb:388:in `process_global_backlog'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/message_bus-4.3.8/lib/message_bus/backends/redis.rb:277:in `block in global_subscribe'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/message_bus-4.3.8/lib/message_bus/backends/redis.rb:289:in `global_subscribe'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/message_bus-4.3.8/lib/message_bus.rb:768:in `global_subscribe_thread'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/message_bus-4.3.8/lib/message_bus.rb:739:in `block in new_subscriber_thread'

El problema es que no veo qué está mal, ya que puedo conectarme al servidor redis en el contenedor a través de redis-cli y establecer y obtener claves sin problemas.

Veo muchos problemas similares en el foro, pero o son antiguos o no tienen ninguna resolución. ¿Alguien puede ayudar? Puedo proporcionar más información si es necesario.

1 me gusta

¿Esto solía funcionar?

¿Hace cuánto tiempo empezaste?

¿Tienes dos versiones de un archivo app.yml estándar, cada una con su propia plantilla de Redis y postgres y diferentes rutas a los datos?

Una posibilidad son los permisos. En algún momento, el id del usuario y grupo utilizados cambiaron, pero no he visto que eso sea un problema en configuraciones de contenedor único.

Gracias por echar un vistazo a mi problema.

Sí, esto solía funcionar hasta hace unos 3 días. Sin embargo, esta mañana intenté ejecutar una copia de seguridad en la CLI desde dentro del contenedor y falló debido a un extraño error de postgres, así que sospecho que la base de datos está corrupta de alguna manera. Lo cual no es relevante en absoluto para el mensaje de error que mencioné anteriormente, pero me inclino a intentar restaurar una copia de seguridad que funcione de hace 8 días (al propietario del foro no le importa) para ver si resuelve todo.

Supongo que puedo restaurar una copia de seguridad de una versión anterior de Discourse a una más reciente. (ya que ha habido una actualización entre la copia de seguridad y ahora).

EDITAR: para aclarar, los dos foros son archivos yaml diferentes, por lo que cada uno tiene su propio contenedor para trabajar y directorios de datos diferentes, obviamente.

¿Falló en la copia de seguridad o en la restauración?

Sería útil si incluyeras el extraño error, pero si fue en la restauración, sospecho que es el que se describe aquí: Restore failing with missing chat_mention function

Si es correcto, mi consejo es esperar. Si esperar no es una opción, podrías intentar ver que el sitio que restauras tenga el mismo commit que el sitio que crea la copia de seguridad.

Está en la copia de seguridad.

pg_dump: error: Volcar el contenido de la tabla "posts" falló: PQgetResult() falló.
pg_dump: error: Mensaje de error del servidor: ERROR:  no se pudo abrir el archivo "base/16384/17044": No existe tal archivo o directorio

Por eso dije que intentaría restaurar una copia de seguridad primero para ver si soluciona el problema. :slight_smile:

Eso sí que parece un problema de base de datos.

¿Has restaurado alguna vez una copia de seguridad del sistema de archivos? Eso suena al tipo de cosa que sucedería si hicieras una copia de seguridad del sistema de archivos mientras la base de datos estaba en funcionamiento. Es una de las razones por las que no recomiendo copias de seguridad del sistema de archivos.

Si quieres restaurar una copia de seguridad de Discourse, que normalmente recomendaría, necesitarías eliminar la base de datos, y crear y migrar una base de datos vacía antes de hacer la restauración.

Hago copias de seguridad del sistema de archivos, pero excluyo las bases de datos de postgres ya que las volco en su lugar. Sin embargo, es posible que haya olvidado excluir la carpeta de discourse, tendré que comprobarlo más tarde.

¿La información de este hilo sigue siendo válida para mi caso de uso?

La información sobre cómo obtener la copia de seguridad donde la necesitas parece innecesariamente complicada.

Okay, encontré al culpable, gracias por señalarme la dirección correcta sobre el sistema de archivos. Ejecutamos un análisis de virus y alguien subió algo al foro que tenía una firma de virus. Como resultado, clamav eliminó el archivo. Lo ajustaré mejor para que ya no ponga en cuarentena los archivos de postgres.

Perdón por la pérdida de tiempo :slight_smile:

1 me gusta

¡Genial! Me alegra que mi pista haya ayudado. Nunca se me habría ocurrido, pero hace mucho tiempo que no ejecuto un antivirus.

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