2013-02-21 21 views
6

Abbiamo problemi con la distribuzione a caldo con unicorno. Utilizziamo praticamente le configurazioni canoniche unicorn.rb, impostiamo il working_directory in modo che punti alla cartella del link simbolico, ma in qualche modo sembra bloccato sulla cartella effettiva al momento del primo avvio e non riesce a seguire il collegamento simbolico.unicorn working_directory con symlink

# config/unicorn.rb 
if ENV['RAILS_ENV'] == 'production' 
    worker_processes 4 
else 
    worker_processes 2 
end 

working_directory "/var/local/project/symlinkfolder" 

# Listen on unix socket 
listen "/tmp/unicorn.sock", :backlog => 64 

pid "/var/run/unicorn/unicorn.pid" 

stderr_path "/var/log/unicorn/unicorn.log" 
stdout_path "/var/log/unicorn/unicorn.log" 

preload_app true 

before_fork do |server, worker| 
    # the following is highly recomended for Rails + "preload_app true" 
    # as there's no need for the master process to hold a connection 
    if defined?(ActiveRecord::Base) 
    ActiveRecord::Base.connection.disconnect! 
    end 

    # Before forking, kill the master process that belongs to the .oldbin PID. 
    # This enables 0 downtime deploys. 
    old_pid = "/var/run/unicorn/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| 
    # the following is *required* for Rails + "preload_app true", 
    if defined?(ActiveRecord::Base) 
    ActiveRecord::Base.establish_connection 
    end 

    # this makes sure the logging-rails framework works when preload_app = true 
    Logging.reopen 
    # if preload_app is true, then you may also want to check and 
    # restart any other shared sockets/descriptors such as Memcached, 
    # and Redis. TokyoCabinet file handles are safe to reuse 
    # between any number of forked children (assuming your kernel 
    # correctly implements pread()/pwrite() system calls) 
end 

Quando emettiamo un USR2, vediamo questo nel registro unicorno:

executing ["/var/local/project/project.d/6/vendor/bundle/ruby/1.9.1/bin/unicorn_rails", "-E", "staging", "-D", "-c", "/var/local/project/symlinkfolder/config/unicorn.rb"│· 
, {12=>#<Kgio::UNIXServer:fd 12>}] (in /var/local/project/project.d/8) 

così unicorno è in qualche modo 'bloccato' in versione 6, mentre la cartella effettiva link simbolico è in versione 8 .. . questo diventa un problema non appena potiamo cartella per la versione 6, dopo qualche implementa ...

  • Il working_directory è impostato per le fol symlink'd der
  • il link simbolico punta a cartella /var/local/project/project.d/[id] correttamente
  • Aggiorniamo il link simbolico prima l'invio del segnale di USR2

Cosa abbiamo manca ??

risposta

7

La soluzione era quella di impostare in modo esplicito il percorso binario unicorno, come spiegato (in modo un po 'confuso) su http://unicorn.bogomips.org/Sandbox.html

app_root = "/var/local/project/symlinkfolder" 
working_directory app_root 
# see http://unicorn.bogomips.org/Sandbox.html 
Unicorn::HttpServer::START_CTX[0] = "#{app_root}/vendor/bundle/ruby/1.9.1/bin/unicorn_rails" 

Poi abbiamo bisogno di emettere un comando (kill -HUP), ricarica in modo unicorno il file unicorn reload config . E da quel momento in poi, l'emissione di un segnale USR2 funziona correttamente.