Avvio delle attività in background con Capistrano

Question

Per la mia app RubyOnRails devo avviare un lavoro in background alla fine della distribuzione di Capistrano. Per questo, ho provato quanto segue in deploy.rb:

run "nohup #{current_path}/script/runner -e production 'Scheduler.start' &", :pty => true 

volte questo funziona, ma il più delle volte non si avvia il processo di (= non compresi ps -aux). E non ci sono messaggi di errore. E non c'è nohup.out, non nella directory home e non nella directory dell'app rails.

Ho provato a usare trap ('SIGHUP', 'IGNORE') in scheduler.rb invece di nohup, ma il risultato è lo stesso.

L'unico modo per farlo funzionare è rimuovere ": pty => true" e fare un Ctrl-C manuale alla fine di "cap deploy". Ma non mi piace ...

Ci sono altre possibilità di richiamare questo Scheduler.start? O per ottenere altri messaggi di errore?

sto usando Rails 2.3.2, 2.5.8 Capistrano, Ubuntu Hardy sul server

Answer 1

volete che il vostro lavoro di pianificazione per eseguire continuamente in background e ottenere riavviato quando si esegue Capistrano?

Se è così, allora per che io uso runit http://smarden.sunsite.dk/runit/ e DelayedJob http://github.com/Shopify/delayed_job/tree/master

1. Installare runit nella modalità di non sostituire init
2. Aggiungi il tuo processo in background come servizio runit e aggiungere il monitor di registro per esso da runit.
3. Avere Capistrano chiama sudo sv kill job_name per uccidere e riavviare il lavoro.

Il mio lavoro di backround è un'istanza del plugin Rails DelayedJob che gestisce le attività di background Rails. Lo uccido con ogni schieramento di Capistrano, quindi verrà riavviato con il codice aggiornato.

Questo ha dimostrato di essere molto affidabile.

HTH,

Larry

Answer 2

Con: pty => true, utente di shell script di avvio (ad esempio bashrc, etc.) sono (di solito) non caricato. Il mio programma ruby ​​è uscito subito dopo l'avvio a causa della mancanza di variabili di ambiente dipendenti.

Senza: pty => true, come descritto nella domanda, capistrano rimane in attesa del processo di uscita. Dovrai reindirizzare sia stdout che stderr per farlo tornare immediatamente.

run 'nohup ruby -e "sleep 5" &' # hangs for 5 seconds 
run 'nohup ruby -e "sleep 5" > /dev/null &' # hangs for 5 seconds 
run 'nohup ruby -e "sleep 5" > /dev/null 2>&1 &' # returns immediately. good. 

Se l'attività in background non viene ancora eseguita. Prova a reindirizzare stdout e stderr in un file di log in modo da poter esaminare l'output.

Answer 3

Se questa utilità di pianificazione ha un opzione -d funzionerà. Ad esempio, il passeggero autonomo ha un'opzione -d per avviarlo come processo demonizzato.

namespace :passenger_standalone do 
    task :start do 
    run "cd #{current_path} && passenger start -e #{rails_env} -d" 
    end 
    task :stop do 
    run "cd #{current_path} && RAILS_ENV=#{rails_env} passenger stop" 
    end 
    task :restart do 
    stop 
    start 
    end 
end 

Answer 4

Mi piacerebbe condividere la mia soluzione che funziona anche quando si eseguono più comandi. Ho provato molte altre varianti trovate online, incluso il trucco "sleep N".

run("nohup sh -c 'cd #{release_path} && bundle exec rake task_namespace:task_name RAILS_ENV=production > ~/shared/log/<rakelog>.log &' > /dev/null 2>&1", :pty => true) 

Questa è una risposta DUP launching background process in capistrano task ma vuole fare in modo gli altri e me può google per questa soluzione.