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