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
- Se tarda casi el 100% de la CPU mientras que a partir
- a veces se establece y soy capaz de utilizarlo
- * 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
¿Alguna vez descubrió esto? Experimenté el mismo problema. – David
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 –
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