No se puede asignar hilo después de actualizar a 2026.4.1

Contribuir Error
1

Estoy viendo estos errores en los registros después de actualizar a 2026.4.1 (e404d9aabc) recientemente:

Mensaje (151769 copias reportadas)

Excepción del trabajo: no se puede asignar un hilo

Rastreo de llamadas

/usr/local/lib/ruby/3.4.0/socket.rb:712:in 'Thread.new'
/usr/local/lib/ruby/3.4.0/socket.rb:712:in 'bloque en Socket.tcp_with_fast_fallback'
/usr/local/lib/ruby/3.4.0/socket.rb:710:in 'Array#map'
/usr/local/lib/ruby/3.4.0/socket.rb:710:in 'Socket.tcp_with_fast_fallback'
/usr/local/lib/ruby/3.4.0/socket.rb:661:in 'Socket.tcp'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/redis-client-0.28.0/lib/redis_client/ruby_connection.rb:122:in 'RedisClient::RubyConnection#connect'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/redis-client-0.28.0/lib/redis_client/ruby_connection.rb:48:in 'RedisClient::RubyConnection#initialize'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/redis-client-0.28.0/lib/redis_client.rb:849:in 'Class#new'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/redis-client-0.28.0/lib/redis_client.rb:849:in 'bloque en RedisClient#connect'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/redis-client-0.28.0/lib/redis_client/middlewares.rb:12:in 'RedisClient::BasicMiddleware#connect'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/redis-client-0.28.0/lib/redis_client.rb:848:in 'RedisClient#connect'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/redis-client-0.28.0/lib/redis_client.rb:824:in 'RedisClient#raw_connection'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/redis-client-0.28.0/lib/redis_client.rb:779:in 'RedisClient#ensure_connected'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/redis-client-0.28.0/lib/redis_client.rb:372:in 'RedisClient#call_v'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/redis-5.4.0/lib/redis/client.rb:90:in 'Redis::Client#call_v'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/rack-mini-profiler-4.0.1/lib/mini_profiler/profiling_methods.rb:90:in 'bloque en Redis::Client#profile_method'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/redis-5.4.0/lib/redis.rb:152:in 'bloque en Redis#send_command'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/redis-5.4.0/lib/redis.rb:151:in 'Monitor#synchronize'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/redis-5.4.0/lib/redis.rb:151:in 'Redis#send_command'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/redis-5.4.0/lib/redis/commands/keys.rb:256:in 'Redis::Commands::Keys#del'
/var/www/discourse/lib/discourse_redis.rb:168:in 'bloque en DiscourseRedis#del'
/var/www/discourse/lib/discourse_redis.rb:29:in 'DiscourseRedis.ignore_readonly'
/var/www/discourse/lib/discourse_redis.rb:165:in 'DiscourseRedis#del'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/mini_scheduler-0.18.0/lib/mini_scheduler/distributed_mutex.rb:48:in 'MiniScheduler::DistributedMutex#synchronize'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/mini_scheduler-0.18.0/lib/mini_scheduler/distributed_mutex.rb:15:in 'MiniScheduler::DistributedMutex.synchronize'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/mini_scheduler-0.18.0/lib/mini_scheduler/manager.rb:365:in 'MiniScheduler::Manager#lock'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/mini_scheduler-0.18.0/lib/mini_scheduler/manager.rb:316:in 'MiniScheduler::Manager#tick'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/mini_scheduler-0.18.0/lib/mini_scheduler.rb:74:in 'bloque (2 niveles) en MiniScheduler.start'

hostname	ip-172-x-x-x-app
process_id	286281
application_version	3532c825824ee1259628545c7bd5311ecb918009
current_db	default
current_hostname	discussion.mcebuddy2x.com
message	Mientras se ejecutaba el administrador de programación
time	7:57 p. m.
2

Esto probablemente sea una restricción de recursos en tu servidor. ¿Qué está haciendo la RAM en este momento? ¿Tienes algún detalle sobre el droplet que estás ejecutando?

3

Es una máquina dedicada que ejecuta únicamente una instancia de Discourse. No parece haber escasez de RAM o swap.

4

¿Cuándo actualizaste por última vez Docker, el sistema operativo y la imagen de Discourse? ¿Está todo en la última versión en los tres?

5

La última vez que se ejecutó una actualización de CLI/docker y del sistema operativo fue la semana pasada. Intentaré hacerlo de nuevo.

IMG2572
IMG25722233×899 382 KB

IMG2571
IMG25711170×537 68 KB

Funcionaba correctamente en la versión beta de hace unas semanas. Esto comenzó después de actualizar de beta a versión estable mediante la opción de actualización del navegador.

6

¿Podrías ejecutar ./launcher enter app y

ulimit -u

esto muestra el número máximo de procesos/hilos de usuario permitidos.

ulimit -a

esto muestra todos los límites de recursos.

cat /sys/fs/cgroup/pids.max

Esto verifica el número máximo de procesos (PIDs) permitidos para el contenedor o el cgroup del sistema.

ahora usa logout para volver al host;

systemctl show docker | grep TasksMax

esto verifica si systemd ha impuesto un límite de tareas/hilos en el servicio Docker.

systemctl show containerd | grep TasksMax

esto realiza el mismo tipo de verificación, pero para el servicio containerd en lugar de Docker directamente.

docker inspect app | grep -i pid

esto verifica los límites y configuraciones de procesos/PIDs de tu contenedor de Discourse. El grep -i pid: filtra cualquier cosa que contenga «pid» (sin distinción de mayúsculas y minúsculas).

Si sigues obteniendo errores, ¿podrías pegar aquí la salida de estos comandos? Eso sería de gran ayuda.

7

./launcher enter app

1 me gusta
8

Aquí está la información, prácticamente todo es ilimitado

IMG2573
IMG25731170×814 167 KB

IMG2574
IMG25741170×180 32.1 KB

IMG2575
IMG2575671×103 13.4 KB

IMG2576
IMG2576662×102 14.6 KB

IMG2577
IMG25771170×180 22.2 KB

9

Hacer una reconstrucción desde la CLI parece haberlo solucionado. Seguiré vigilándolo. Algo relacionado con la actualización del navegador de la versión beta a la estable la semana pasada desencadenó este problema.

¿Debería haber límites para la actualización del navegador? ¿Puede la actualización detectar problemas potenciales y señalarlos o evitar que se active la actualización?

1 me gusta
10

La reconstrucción probablemente restableció la ubicación del cgroup del contenedor, lo que explicaría por qué ha vuelto a ser estable.

Dado los errores originales de “can’t alloc thread” y el hecho de que todo lo demás (ulimits, TasksMax, PIDs de Docker) esté ilimitado, el sospechoso restante es la presión del cgroup de PIDs.

¿Podrías verificar durante la carga normal:

cat /sys/fs/cgroup/pids.current

[1]

cat /sys/fs/cgroup/pids.max

[2]

Si pids.current se acerca a ~2000+ frente a un máximo de ~2285, eso confirmaría que el contenedor estaba alcanzando el límite de PIDs del cgroup durante los ráfagas de reintentos del programador / Redis.

Eso también explicaría por qué el problema solo apareció después de la actualización (mayor churn de hilos) y por qué la reconstrucción lo solucionó temporalmente.

  1. Cuántos procesos (PIDs/hilos) se están ejecutando actualmente dentro del contenedor/cgroup ↩︎

  2. el número máximo de procesos (PIDs/hilos) permitidos en ese cgroup (tu contenedor) ↩︎

1 me gusta
11

Ni siquiera se acerca: los actuales 227 frente a un máximo de 4194304

12

Gracias, eso descarta una presión actual de PIDs después de la reconstrucción.

Dado que pids.current es solo 227 frente a 4194304, el contenedor definitivamente no está cerca del límite de PIDs del cgroup ahora.

Lo interesante es que el pids.max anterior parecía ser 2285, mientras que después de la reconstrucción ahora es 4194304. Por lo tanto, la reconstrucción puede haber restablecido el límite del cgroup (es decir, renovado el contenedor de la aplicación), lo que explica por qué no hay evidencia de un problema activo de agotamiento de PIDs en este momento.

Si el error vuelve a aparecer, sería útil copiar y pegar estos comandos en el momento en que falle:

cat /sys/fs/cgroup/pids.current

cat /sys/fs/cgroup/pids.max

ps -eLf | wc -l

Esto mostraría si el fallo se debe a una presión de PIDs, o si deberíamos buscar en otro lugar :slightly_smiling_face: