Administro una instalación de Discourse autoalojada (2026.5.0-latest). Hoy intenté activar YJIT. Añadí "templates/enable-ruby-yjit.yml" a containers/app.yml y reconstruí la aplicación.
Una vez finalizada la reconstrucción, ocurrió algo interesante. Dentro del contenedor Docker, ejecuté env | grep RUBY_YJIT_ENABLE y obtuve RUBY_YJIT_ENABLE=1. Hasta ahí todo bien. Pero luego ejecuté sudo -u discourse RAILS_ENV=production bundle exec rails runner 'puts "YJIT enabled: #{RubyVM::YJIT.enabled?}"; puts RUBY_DESCRIPTION'… y obtuve:
Por lo tanto, YJIT no se activó, a pesar de haber añadido la plantilla enable-ruby-yjit.yml. Entonces, cuando ejecuté sudo -u discourse RAILS_ENV=production bundle exec rails runner 'puts "GlobalSetting.yjit_enabled=#{GlobalSetting.yjit_enabled}"', obtuve GlobalSetting.yjit_enabled= — ¡un valor nulo!
En cualquier caso, después de experimentar un poco más con ello, finalmente logré activar YJIT añadiendo lo siguiente a containers/app.yml:
env:
DISCOURSE_YJIT_ENABLED: true
Estoy seguro de que hay un error en algún lugar (GlobalSetting.yjit_enabledno debería devolver nunca nil), pero establecer la variable de entorno funcionó, y espero que alguien que busque esto en Google encuentre este tema.
Observar la presencia de una variable de entorno no te dice nada sobre si Ruby se está ejecutando actualmente con YJIT habilitado. En este caso particular, la variable de entorno está definida, pero algo más estaba sobrescribiendo la variable que Rails utiliza para habilitar (o deshabilitar) YJIT al iniciar. No hay otra explicación para que GlobalSetting.yjit_enabled= devuelva nil, incluso en una nueva instancia de Rails. Tampoco hay ninguna razón por la cual YJIT deba estar desactivado en una nueva instancia de Rails.
Después de agregar la variable de entorno DISCOURSE_YJIT_ENABLED a mi containers/app.yml:
Esto es incorrecto. A nivel de Ruby, la variable de entorno es uno de los interruptores oficiales; consulta la documentación oficial de Ruby al respecto aquí:
Esto es incorrecto, ya que DISCOURSE_YJIT_ENABLED solo alimenta GlobalSetting.yjit_enabled → config.yjit en config/application.rb. Rails usa eso para habilitar YJIT si no está ya activo. No deshabilita un YJIT que ya esté habilitado. Por lo tanto, cuando la variable de entorno está establecida, DISCOURSE_YJIT_ENABLED no tiene ninguna función.
Para demostrar aún más mi punto, escribí un plugin que devuelve si YJIT está habilitado en mi proceso web:
¡Vaya! ¿Estás diciendo que podemos usar de forma fiable la variable de entorno para detectar si YJIT está habilitado? No lo sabía; gracias por el enlace a la documentación de Ruby.
Sin embargo, tengo una pequeña confusión. ¿Cómo es posible que env | grep RUBY_YJIT_ENABLE devuelva RUBY_YJIT_ENABLE=1, pero una nueva instancia de Rails en el mismo contenedor, al pedirle que imprima #{RubyVM::YJIT.enabled?}, muestre false? ¿No debería mostrar true, ya que, como mencionaste, esta variable de entorno funciona a nivel de Ruby?
Probablemente estés muy ocupado y esto no debería importar, así que no es necesario que respondas. Debería poder resolverlo yo mismo en mi servidor. ¿Por casualidad podrías compartirme tu plugin? Quiero una forma de estar seguro de que mi servidor Discourse se está ejecutando en Ruby con YJIT habilitado.
Marcaré tu respuesta como solución después de haberla replicado.
sudo -u discourse limpia el entorno. Usar la bandera -E incluye el entorno normal, y en ese caso sudo -E -u discourse RAILS_ENV=production bundle exec rails runner 'puts "YJIT enabled: #{RubyVM::YJIT.enabled?}"; puts RUBY_DESCRIPTION' devuelve
Me disculpo por hacerte perder el tiempo y he marcado tu respuesta como la solución. Lo siento por esto. Gracias por investigar y tomarte el tiempo de responder.