10

Tengo un problema extraño en la puesta en escena después de migrar a unicornio de pasajero.unicornio cuelga diciendo Refreshing Gems

Configuré unicornio para el entorno de desarrollo y de transición. está trabajando en desarrollo pero no en etapas. En desarrollo, está escuchando 8080 donde, como en la puesta en escena, está escuchando un socket de Unix. ¿Eso hará alguna diferencia? Especialmente en la producción un poco env?

Esto es lo que sucede cuando lo funciono en la organización de

  1. Se tarda casi el 100% de la CPU mientras que a partir
  2. a veces se establece y soy capaz de utilizarlo
  3. * Pero la mayor parte del veces se bloquea ** y tuve que matarlo.

He conectado una pregunta con respecto a este tema click here

Esto es lo que veo en unicorn.stderr.log

I, [2011-08-26T09:02:53.324286 #5026] INFO -- : unlinking existing socket=/home/krishnaprasad/project_name/tmp/sockets/unicorn.sock 
I, [2011-08-26T09:02:53.324502 #5026] INFO -- : listening on addr=/home/krishnaprasad/project_name/tmp/sockets/unicorn.sock fd=3 
I, [2011-08-26T09:02:53.324860 #5026] INFO -- : Refreshing Gem list 

¿por qué se intente actualizar las gemas? ¿hay alguna forma de evitarlo en el archivo de configuración?

esto es lo que tengo en config/unicorn_staging.rb

# unicorn_rails -c /config/unicorn_staging.rb -E staging -D 

rails_env = 'staging' 

working_directory "/home/krishnaprasad/Projects/project_name" 
worker_processes 1 
preload_app true 
timeout 90 

rails_root = "/home/krishnaprasad/Projects/project_name" 
listen "#{rails_root}/tmp/sockets/unicorn.sock", :backlog => 2048 

pid "#{rails_root}/tmp/pids/unicorn.pid" 
stderr_path "#{rails_root}/log/unicorn.log" 
stdout_path "#{rails_root}/log/unicorn.log" 

GC.copy_on_write_friendly = true if GC.respond_to?(:copy_on_write_friendly=) 

before_fork do |server, worker| 
    ActiveRecord::Base.connection.disconnect! 
    old_pid = "#{Rails.root}/tmp/pids/unicorn.pid.oldbin" 
    if File.exists?(old_pid) && server.pid != old_pid 
    begin 
     Process.kill("QUIT", File.read(old_pid).to_i) 
    rescue Errno::ENOENT, Errno::ESRCH 
     # someone else did our job for us 
    end 
    end 
end 

after_fork do |server, worker| 
    ActiveRecord::Base.establish_connection 
end 

Cualquier ayuda muy apreciada. Gracias de antemano

+0

¿Alguna vez descubrió esto? Experimenté el mismo problema. – David

+0

eliminé esta línea y encontré que funciona un poco, pero aún así es lenta after_fork do | server, worker | ActiveRecord :: Base.establish_connection end –

+0

Parece que eliminar esa línea provocará problemas con los identificadores de base de datos compartidos en los subprocesos de unicornio. Terminé simplemente no poder ejecutar Unicorn en modo daemon con la aplicación de precarga. Una vez que deshabilité la aplicación de precarga, dejó de causar problemas. – David

Respuesta

0

¡Asegúrese de que su código esté libre de errores de sintaxis!

Para mí, la reparación de un error de sintaxis (en uno de mis controladores) finalizó el ciclo y comenzó correctamente el Unicornio. No recibí ningún mensaje de error en Unicorn, es posible que desee intentar comenzar a usar WebRat y ver si aparece un error.

0

Para mí, fue la conexión de la base de datos no configurada correctamente. Parece que a veces informa esto en la consola, a veces simplemente gira.