Prueba de latido de Sidekiq falló, reiniciando

Soporte Instalación
1

¡Hola! Encontré un error extraño en mi página de administración: Sidekiq no se está ejecutando.
Abí los registros y encontré cientos de errores como este:

/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/logster-2.5.1/lib/logster/logger.rb:112:in `report_to_store'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/logster-2.5.1/lib/logster/logger.rb:103:in `add_with_opts'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/logster-2.5.1/lib/logster/logger.rb:54:in `add'
/usr/local/lib/ruby/2.6.0/logger.rb:534:in `warn'
config/unicorn.conf.rb:147:in `check_sidekiq_heartbeat'
config/unicorn.conf.rb:164:in `master_sleep'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/unicorn-5.5.2/lib/unicorn/http_server.rb:296:in `join'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/unicorn-5.5.2/bin/unicorn:128:in `<top (required)>'
/var/www/discourse/vendor/bundle/ruby/2.6.0/bin/unicorn:23:in `load'
/var/www/discourse/vendor/bundle/ruby/2.6.0/bin/unicorn:23:in `<main>'

Aquí están los errores de la aplicación:

run-parts: ejecutando /etc/runit/1.d/00-ensure-links
run-parts: ejecutando /etc/runit/1.d/00-fix-var-logs
run-parts: ejecutando /etc/runit/1.d/anacron
run-parts: ejecutando /etc/runit/1.d/cleanup-pids
Limpieza de archivos PID obsoletos
run-parts: ejecutando /etc/runit/1.d/copy-env
run-parts: ejecutando /etc/runit/1.d/letsencrypt
[Wed 01 Jan 2020 10:40:41 AM UTC] Los dominios no han cambiado.
[Wed 01 Jan 2020 10:40:41 AM UTC] Omitido, la próxima fecha de renovación es: Tue Feb 25 00:52:11 UTC 2020
[Wed 01 Jan 2020 10:40:41 AM UTC] Agregue '--force' para forzar la renovación.
[Wed 01 Jan 2020 10:40:41 AM UTC] Instalando la clave en: /shared/ssl/discourse.example.com.key
[Wed 01 Jan 2020 10:40:41 AM UTC] Instalando la cadena completa en: /shared/ssl/discourse.example.com.cer
[Wed 01 Jan 2020 10:40:41 AM UTC] Ejecutando el comando de recarga: sv reload nginx
advertencia: nginx: no se pudo abrir supervise/ok: el archivo no existe
[Wed 01 Jan 2020 10:40:41 AM UTC] Error de recarga para :
[Wed 01 Jan 2020 10:40:42 AM UTC] Los dominios no han cambiado.
[Wed 01 Jan 2020 10:40:42 AM UTC] Omitido, la próxima fecha de renovación es: Wed Jan  8 00:39:10 UTC 2020
[Wed 01 Jan 2020 10:40:42 AM UTC] Agregue '--force' para forzar la renovación.
[Wed 01 Jan 2020 10:40:42 AM UTC] Instalando la clave en: /shared/ssl/discourse.example.com_ecc.key
[Wed 01 Jan 2020 10:40:42 AM UTC] Instalando la cadena completa en: /shared/ssl/discourse.example.com_ecc.cer
[Wed 01 Jan 2020 10:40:42 AM UTC] Ejecutando el comando de recarga: sv reload nginx
advertencia: nginx: no se pudo abrir supervise/ok: el archivo no existe
[Wed 01 Jan 2020 10:40:42 AM UTC] Error de recarga para :
Se inició runsvdir, el PID es 628
chgrp: grupo no válido: 'syslog'
rsyslogd: imklog: no se pudo abrir el registro del kernel (/proc/kmsg): Operación no permitida.
rsyslogd: falló la activación del módulo imklog [v8.1901.0 consulta https://www.rsyslog.com/e/2145 ]
PID del supervisor: 633, PID de unicorn: 647
```\n
Intenté limpiar la base de datos de Redis, pero no ayudó.
Tengo contenedores separados para la aplicación, PostgreSQL y Redis.
¿Alguna idea sobre cómo solucionar esto?
2

¿Está Sidekiq en pausa? ¿Se están acumulando los trabajos en la cola?

3

Muestra 2 trabajos en la cola predeterminada, ambos son Jobs::VersionCheck.
Después de limpiar la base de datos de Redis, muestra 0 trabajos completados, 0 fallidos y 2 en cola.

La página del programador muestra que algunos trabajos están en cola o en ejecución, pero estos trabajos no se cuentan en las estadísticas de la página de Sidekiq. Todos los trabajos en la página del programador tienen una duración vacía o de -1 ms.

Así que los números no se acumulan, literalmente nada cambia.
¿Cómo puedo verificar si Sidekiq está pausado?

4

El mismo problema aquí con la última actualización. No hubo cambios más que la propia actualización mediante una reconstrucción; el panel de administración indica que Sidekiq no se está ejecutando. Tengo PostgreSQL y Redis en un contenedor y la aplicación en otro; también los he reiniciado todos. Las colas tienen varias cientos de elementos, pero nada está siendo procesado.

EDIT1: Limpiar todas las colas no solucionó ni ayudó en nada; se están rellenando de nuevo y siguen sin procesarse.

EDIT2: He reconstruido el foro con toda la interrupción de servicio que eso conlleva, y sigo viendo este mensaje:

image
image1084×160 14.4 KB

Y las colas no se procesan en /sidekiq. Todo esto funcionaba sin problemas antes de actualizar de beta7 a 2.4.0.beta9.

EDIT3: Más de 50 GB de espacio libre. Ejecutar manualmente una copia de seguridad (casi 300 MB) funciona correctamente; indica que pausa y reanuda Sidekiq y no reporta errores en el registro, pero Sidekiq sigue sin parecer estar en ejecución.

EDIT4: El único registro relevante en /logs es el de Sidekiq heartbeat test failed, restarting, que se repite continuamente.

EDIT5: Redis parece estar activo y funcionando bien; al menos su archivo de registro está ocupado diciendo que no tiene mucho que hacer… Y para mayor claridad:

[3] pry(main)> Sidekiq.paused?
=> false

EDIT6: Limpié las colas hace un rato; ahora hay 10 tareas en cola de nuevo, pero no se están procesando.

EDIT7: Descubrí que bundle exec sidekiq es la forma habitual de iniciar Sidekiq en un proyecto normal, así que probemos ejecutarlo para ver qué ocurre:

root@vps198273-forum:/var/www/discourse# bundle exec sidekiq
2020-01-06T05:10:18.814Z pid=31242 tid=gn383wxbu INFO: Booting Sidekiq 6.0.4 with redis options {:host=>"forum-data", :port=>6379, :namespace=>"sidekiq", :id=>"Sidekiq-server-PID-31242", :url=>nil}
You are connecting to Redis v3.0.6, Sidekiq requires Redis v4.0.0 or greater
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/sidekiq-6.0.4/lib/sidekiq/cli.rb:62:in `run'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/sidekiq-6.0.4/bin/sidekiq:12:in `<top (required)>'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/sidekiq-6.0.4/bin/sidekiq:23:in `load'
/var/www/discourse/vendor/bundle/ruby/2.6.0/bin/sidekiq:23:in `<top (required)>'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.1/lib/bundler/cli/exec.rb:63:in `load'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.1/lib/bundler/cli/exec.rb:63:in `kernel_load'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.1/lib/bundler/cli/exec.rb:28:in `run'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.1/lib/bundler/cli.rb:476:in `exec'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.1/lib/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.1/lib/bundler/vendor/thor/lib/thor/invocation.rb:127:in `invoke_command'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.1/lib/bundler/vendor/thor/lib/thor.rb:399:in `dispatch'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.1/lib/bundler/cli.rb:30:in `dispatch'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.1/lib/bundler/vendor/thor/lib/thor/base.rb:476:in `start'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.1/lib/bundler/cli.rb:24:in `start'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.1/exe/bundle:46:in `block in <top (required)>'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.1/lib/bundler/friendly_errors.rb:123:in `with_friendly_errors'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.1/exe/bundle:34:in `<top (required)>'
/usr/local/bin/bundle:23:in `load'
/usr/local/bin/bundle:23:in `<main>'

You are connecting to Redis v3.0.6, Sidekiq requires Redis v4.0.0 or greater

Bueno, esto parece interesante. Probemos reconstruir el contenedor de datos y rezar para no tocar los datos, lol…

EDIT8: Parece que está ejecutando Redis 5.0.5 (¿por qué no se usa pubsub de PostgreSQL para esto?), que definitivamente es 4.0.0 o superior… y ha terminado de reconstruirse. Probando el foro, sus datos siguen ahí y ¡tenemos un pico!

image
image367×572 61.8 KB

¡Parece arreglado! Quizás este post sea útil para alguien. Ojalá el foro me hubiera mostrado el error que Sidekiq estaba dando sobre una versión obsoleta de Redis, pero supongo que esos registros se van al vacío en algún lugar, ya que no los vi en ningún lado. ^.^

5

Este es un excelente trabajo de investigación; espero que ayude a otros.

6

¿Cómo conseguiste un Redis antiguo? ¿Estás usando una instalación no estándar?

7

Uso una configuración de múltiples contenedores y nunca reconstruí Redis.
Probaré reconstruir Redis.

ACTUALIZACIÓN.
@OvermindDL1, gracias por las soluciones. Reconstruí el contenedor de Redis y ahora todo funciona.

Sidekiq es una biblioteca de tareas en segundo plano y depende de Redis. Está súper optimizada y es madura, pero solo admite el backend de Redis.
También creo que message_bus (las funciones en tiempo real de Discourse) utiliza Redis en su interior.

8

Instalación estándar de contenedores divididos con Docker según las instrucciones (para poder construir una nueva versión de Discourse y luego intercambiarlas rápidamente sin tiempo de inactividad), pero no toco el contenedor de datos, que es donde aparentemente se está ejecutando Redis (pensé que estaría en el contenedor principal; me sorprendió no encontrarlo ejecutándose allí).

Sí, exactamente lo mismo que @arrowcircle aquí. :slight_smile:

9

En una configuración de 2 contenedores, aún necesitas reconstruir el contenedor de datos; te recomiendo programarlo al menos una vez al año.

10

¿Hay alguna forma de hacerlo sin tiempo de inactividad? Ese fue el punto de separarlos inicialmente.

11

Para lograr cero tiempo de inactividad, necesitarías ejecutar réplicas de Redis y de la base de datos. Aún así, tendrías una breve fase de solo lectura durante el cambio de failover.

Sí, todo esto es posible, pero necesitarías contratar un equipo de infraestructura.

12

Aquí todo es de código abierto, sin dinero. ^.^;