Capistrano non riavvia i cluster Mongrel correttamente

Question

Ho un cluster di tre ibridi in esecuzione sotto nginx e distribuisco l'app usando Capistrano 2.4.3. Quando "cap cap deploy" quando c'è un sistema in esecuzione, il comportamento è:

1. L'app è distribuita. Il codice è stato aggiornato con successo.

2. Nell'output di distribuzione cap, c'è questo:

   • eseguendo " sudo -p 'sudo password:' cluster mongrel_rails :: restart -C /var/www/rails/myapp/current/config/mongrel_cluster.yml"
   • server: [" myip "]
   • [myip] comando di esecuzione
   • ** [out :: myip] arresto porta 9096
   • ** [out :: myip] arresto porta 9097
   • ** [out :: myip] arresto porta 9098
   • ** [out :: myip] ha già avviato la porta 9096
   • ** [out :: myip] ha già avviato la porta 9097
   • ** [out :: myip] ha già avviato la porta 9098
3. Controllo immediatamente sul server e trovo che Mongrel sia ancora in esecuzione e che i file PID siano ancora presenti per le tre precedenti istanze.
4. Poco dopo (meno di un minuto), trovo che Mongrel non è più in esecuzione, i file PID sono spariti e non è stato possibile riavviare.
5. Se avvio a mano ibrida sul server, l'app si avvia correttamente.

Sembra che 'cluster mongrel_rails :: restart' non sia in attesa di un arresto completo prima di tentare un riavvio del cluster. Come posso diagnosticare e risolvere questo problema?

EDIT: ecco la risposta:

mongrel_cluster, nel campo " riavvia " compito, semplicemente fa questo:

 def run
   stop
   start
 end

Non fa alcuna attesa o verifica per vedere che il processo è terminato prima di invocare " start " ;. Questo è un bug noto con una patch eccezionale inviata . Ho applicato la patch a Mongrel Cluster e il problema è scomparso.

Answer 1

Puoi esplicitamente dire alle ricette mongrel_cluster di rimuovere i file pid prima di iniziare aggiungendo quanto segue nelle tue ricette capistrano:

# helps keep mongrel pid files clean
set :mongrel_clean, true

Questo fa sì che passi l'opzione --clean a mongrel_cluster_ctl.

Sono tornato indietro e ho esaminato una delle mie ricette di distribuzione e ho notato che avevo anche cambiato il modo in cui la mia attività di riavvio funzionava. Dai un'occhiata al seguente messaggio nel gruppo utenti mongrel:

discussione di riavviamento degli utenti

La seguente è la mia attività deploy: restart. Ammetto che è un po 'un trucco.

namespace :deploy do
  desc "Restart the Mongrel processes on the app server."
  task :restart, :roles => :app do
    mongrel.cluster.stop
    sleep 2.5
    mongrel.cluster.start
  end
end

Answer 2

Per prima cosa, restringere l'ambito di ciò che il test chiama solo cap deploy: restart . Potresti voler passare l'opzione --debug per richiedere prima dell'esecuzione remota o l'opzione --dry-run solo per vedere cosa sta succedendo mentre modifichi le tue impostazioni.

A prima vista, questo sembra un problema di permessi sui file pid o sui processi ibridi, ma è difficile saperlo con certezza. Un paio di cose che catturano la mia attenzione sono:

• la variabile : runner è esplicitamente impostata su nil - C'era un motivo specifico per questo?
• Capistrano 2.4 ha introdotto un nuovo comportamento per la variabile : admin_runner . Senza vedere l'intera ricetta, questo è forse correlato al tuo problema?

    

  : runner vs.: admin_runner (da capistrano 2.4 release )   Alcuni capper hanno notato che avere deploy: setup e deploy: cleanup viene eseguito mentre l'utente: runner ha incasinato le proprie autorizzazioni accuratamente predisposte. Ho concordato che questo era un problema. Con questa versione, deploy: start, deploy: stop e deploy: restart tutti continuano a utilizzare l'utente: runner durante il sudo, ma deploy: setup e deploy: cleanup utilizzerà l'utente: admin_runner. La variabile: admin_runner non è impostata, per impostazione predefinita, il che significa che quelle attività verranno eseguite come root, ma se vuoi che vengano eseguite come: runner, fai semplicemente “set: admin_runner, runner”.

La mia raccomandazione su cosa fare dopo. Fermare manualmente i bastardi e ripulire i PID. Avvia i bastardi manualmente. Quindi, continua a eseguire cap deploy: restart durante il debug del problema. Ripeti se necessario.

Answer 3

Ad ogni modo, i miei bastardi stanno iniziando prima che il precedente comando di arresto abbia finito di spegnerli tutti.

sleep 2.5 non è una buona soluzione, se ci vogliono più di 2,5 secondi per fermare tutti i bastardi in esecuzione.

Sembra che sia necessario:

stop && start

vs.

stop; start

(ecco come funziona bash, & amp; & amp; attende che il primo comando finisca senza errore, mentre " ;; " esegue semplicemente il comando successivo).

Mi chiedo se esista un:

wait cluster_stop
then cluster_start

Answer 4

Odio essere così semplice, ma sembra che i file pid siano ancora in giro quando sta tentando di avviarsi. Assicurati che il bastardo venga fermato a mano. Pulisci i file pid a mano. Quindi distribuire un limite.

Answer 5

Buona discussione: http://www.ruby-forum.com/topic/ 139734 # 745030