Backgroundrb devel - Feb 2007 - Deploying to production with backgroundrb (capistrano)

I have noticed that occasionally (about 50% of the time) when i  
deploy (using capistrano) my app to a production server, i have to  
ssh into the box and manually
stop and start backgroundrb to get it to load my workers.

  this is my basic setup

i have 2 workers:

lib/workers/mp3_worker.rb  => takes a hash of params to downsample an  
mp3
lib/workers/flv_worker.rb  =>  takes a has of arguments to compose a  
command line to convert a file into flv

in my recipe
config/deploy.rb

  i have 2 lines
   run "#{current_path}/script/backgroundrb stop"
   run "#{current_path}/script/backgroundrb start"

that should stop the server and restart it.

  after the deploy, i have started sshing in tot he box and running

script/backgroundrb console

and checking the loaded_worker_classes

about 50% of the time, its empty. no classes loaded.

if i manually run those commands, it starts and they load.  identical  
command. different (and upredictable) results.

how would i go about ensuring that when i deploy that backgroundrb  
restarts properly?  ideally i will only be restarting backgroundrb  
when i have model changes or worker class changes that would affect  
it''s operation.


Jerrod Blavos
ph. 919.341.0143
fx.  482.492.5009
jerrod at indierockmedia.com



-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20070205/1463d282/attachment-0001.html

Hey Jerrod-

	You need to use nohup in your tasks to start bdrb.

task :before_restart, :roles => :app do
   restart_backgroundrb
end

task :start_backgroundrb, :roles => :app do
   sudo "nohup /data/#{application}/current/script/backgroundrb start
"
end

task :stop_backgroundrb, :roles => :app do
   sudo "kill -9 `cat /data/#{application}/current/log/ 
backgroundrb.pid` 2>/dev/null; true"
end

task :restart_backgroundrb, :roles => :app do
   stop_backgroundrb
   start_backgroundrb
end

Cheers-
-Ezra

On Feb 5, 2007, at 10:48 AM, Jerrod Blavos wrote:
> I have noticed that occasionally (about 50% of the time) when i  
> deploy (using capistrano) my app to a production server, i have to  
> ssh into the box and manually
> stop and start backgroundrb to get it to load my workers.
>
>  this is my basic setup
>
> i have 2 workers:
>
> lib/workers/mp3_worker.rb  => takes a hash of params to downsample  
> an mp3
> lib/workers/flv_worker.rb  =>  takes a has of arguments to compose  
> a command line to convert a file into flv
>
> in my recipe
> config/deploy.rb
>
>  i have 2 lines
>   run "#{current_path}/script/backgroundrb stop"
>   run "#{current_path}/script/backgroundrb start"
>
> that should stop the server and restart it.
>
>  after the deploy, i have started sshing in tot he box and running
>
> script/backgroundrb console
>
> and checking the loaded_worker_classes
>
> about 50% of the time, its empty. no classes loaded.
>
> if i manually run those commands, it starts and they load.   
> identical command. different (and upredictable) results.
>
> how would i go about ensuring that when i deploy that backgroundrb  
> restarts properly?  ideally i will only be restarting backgroundrb  
> when i have model changes or worker class changes that would affect  
> it''s operation.
>
>
> Jerrod Blavos
> ph. 919.341.0143
> fx.  482.492.5009
> jerrod at indierockmedia.com
>
>
>
> _______________________________________________
> Backgroundrb-devel mailing list
> Backgroundrb-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/backgroundrb-devel
-- Ezra Zygmuntowicz 
-- Lead Rails Evangelist
-- ez at engineyard.com
-- Engine Yard, Serious Rails Hosting
-- (866) 518-YARD (9273)

Hey Ez,

Is there some reason why the stop task doesn''t just use nohup to  
invoke the stop process in the backgroundrb script?
I was going to add these to my deploy.rb and noticed that.

As always thanks for your awesome work with backgroundrb and your  
help. Has anyone else used these tasks in their deploy.rb?

-Michael
http://javathehutt.blogspot.com

On Feb 5, 2007, at 11:22 AM, Ezra Zygmuntowicz wrote:
> Hey Jerrod-
>
> 	You need to use nohup in your tasks to start bdrb.
>
> task :before_restart, :roles => :app do
>    restart_backgroundrb
> end
>
> task :start_backgroundrb, :roles => :app do
>    sudo "nohup /data/#{application}/current/script/backgroundrb  
> start "
> end
>
> task :stop_backgroundrb, :roles => :app do
>    sudo "kill -9 `cat /data/#{application}/current/log/
> backgroundrb.pid` 2>/dev/null; true"
> end
>
> task :restart_backgroundrb, :roles => :app do
>    stop_backgroundrb
>    start_backgroundrb
> end
>
> Cheers-
> -Ezra
>
> On Feb 5, 2007, at 10:48 AM, Jerrod Blavos wrote:
>
>> I have noticed that occasionally (about 50% of the time) when i
>> deploy (using capistrano) my app to a production server, i have to
>> ssh into the box and manually
>> stop and start backgroundrb to get it to load my workers.
>>
>>  this is my basic setup
>>
>> i have 2 workers:
>>
>> lib/workers/mp3_worker.rb  => takes a hash of params to downsample
>> an mp3
>> lib/workers/flv_worker.rb  =>  takes a has of arguments to compose
>> a command line to convert a file into flv
>>
>> in my recipe
>> config/deploy.rb
>>
>>  i have 2 lines
>>   run "#{current_path}/script/backgroundrb stop"
>>   run "#{current_path}/script/backgroundrb start"
>>
>> that should stop the server and restart it.
>>
>>  after the deploy, i have started sshing in tot he box and running
>>
>> script/backgroundrb console
>>
>> and checking the loaded_worker_classes
>>
>> about 50% of the time, its empty. no classes loaded.
>>
>> if i manually run those commands, it starts and they load.
>> identical command. different (and upredictable) results.
>>
>> how would i go about ensuring that when i deploy that backgroundrb
>> restarts properly?  ideally i will only be restarting backgroundrb
>> when i have model changes or worker class changes that would affect
>> it''s operation.
>>
>>
>> Jerrod Blavos
>> ph. 919.341.0143
>> fx.  482.492.5009
>> jerrod at indierockmedia.com
>>
>>
>>
>> _______________________________________________
>> Backgroundrb-devel mailing list
>> Backgroundrb-devel at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/backgroundrb-devel
>
> -- Ezra Zygmuntowicz 
> -- Lead Rails Evangelist
> -- ez at engineyard.com
> -- Engine Yard, Serious Rails Hosting
> -- (866) 518-YARD (9273)
>
>
> _______________________________________________
> Backgroundrb-devel mailing list
> Backgroundrb-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/backgroundrb-devel

Yeah the reason is thast nohup is not needed when you start bdrb  
from the machine its runing on. It''s only needed when calling it via  
capistrano because if you don''t use nohup when cap disconnects from  
the server the bdrb will get killed. It''s an annoying little issue  
that the only workaround is to call it with nohup when calling it  
from cap.

-Ezra


On Feb 27, 2007, at 12:02 PM, Michael Kovacs wrote:
> Hey Ez,
>
> Is there some reason why the stop task doesn''t just use nohup to
> invoke the stop process in the backgroundrb script?
> I was going to add these to my deploy.rb and noticed that.
>
> As always thanks for your awesome work with backgroundrb and your
> help. Has anyone else used these tasks in their deploy.rb?
>
> -Michael
> http://javathehutt.blogspot.com
>
> On Feb 5, 2007, at 11:22 AM, Ezra Zygmuntowicz wrote:
>
>> Hey Jerrod-
>>
>> 	You need to use nohup in your tasks to start bdrb.
>>
>> task :before_restart, :roles => :app do
>>    restart_backgroundrb
>> end
>>
>> task :start_backgroundrb, :roles => :app do
>>    sudo "nohup /data/#{application}/current/script/backgroundrb
>> start "
>> end
>>
>> task :stop_backgroundrb, :roles => :app do
>>    sudo "kill -9 `cat /data/#{application}/current/log/
>> backgroundrb.pid` 2>/dev/null; true"
>> end
>>
>> task :restart_backgroundrb, :roles => :app do
>>    stop_backgroundrb
>>    start_backgroundrb
>> end
>>
>> Cheers-
>> -Ezra
>>
>> On Feb 5, 2007, at 10:48 AM, Jerrod Blavos wrote:
>>
>>> I have noticed that occasionally (about 50% of the time) when i
>>> deploy (using capistrano) my app to a production server, i have to
>>> ssh into the box and manually
>>> stop and start backgroundrb to get it to load my workers.
>>>
>>>  this is my basic setup
>>>
>>> i have 2 workers:
>>>
>>> lib/workers/mp3_worker.rb  => takes a hash of params to
downsample
>>> an mp3
>>> lib/workers/flv_worker.rb  =>  takes a has of arguments to
compose
>>> a command line to convert a file into flv
>>>
>>> in my recipe
>>> config/deploy.rb
>>>
>>>  i have 2 lines
>>>   run "#{current_path}/script/backgroundrb stop"
>>>   run "#{current_path}/script/backgroundrb start"
>>>
>>> that should stop the server and restart it.
>>>
>>>  after the deploy, i have started sshing in tot he box and running
>>>
>>> script/backgroundrb console
>>>
>>> and checking the loaded_worker_classes
>>>
>>> about 50% of the time, its empty. no classes loaded.
>>>
>>> if i manually run those commands, it starts and they load.
>>> identical command. different (and upredictable) results.
>>>
>>> how would i go about ensuring that when i deploy that backgroundrb
>>> restarts properly?  ideally i will only be restarting backgroundrb
>>> when i have model changes or worker class changes that would affect
>>> it''s operation.
>>>
>>>
>>> Jerrod Blavos
>>> ph. 919.341.0143
>>> fx.  482.492.5009
>>> jerrod at indierockmedia.com
>>>
>>>
>>>
>>> _______________________________________________
>>> Backgroundrb-devel mailing list
>>> Backgroundrb-devel at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/backgroundrb-devel
>>
>> -- Ezra Zygmuntowicz 
>> -- Lead Rails Evangelist
>> -- ez at engineyard.com
>> -- Engine Yard, Serious Rails Hosting
>> -- (866) 518-YARD (9273)
>>
>>
>> _______________________________________________
>> Backgroundrb-devel mailing list
>> Backgroundrb-devel at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/backgroundrb-devel
>
> _______________________________________________
> Backgroundrb-devel mailing list
> Backgroundrb-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/backgroundrb-devel
>
-- Ezra Zygmuntowicz 
-- Lead Rails Evangelist
-- ez at engineyard.com
-- Engine Yard, Serious Rails Hosting
-- (866) 518-YARD (9273)