Backgroundrb devel - Feb 2009 - Fails to start via Capistrano?

Hi,

I have a production environment setup on CentOS 5.2. Latest versions  
of backgroundrb and associated gems.

When I run script/backgroundrb start directly from the command line on  
the server is starts fine.

"RAILS_ENV=production script/backgroundrb start"

However the following capistrano task doesn''t seem to work correctly.  
It creates the pid file containing what looks like a valid id but when  
looking for the running process with "ps -aux | grep background"  
nothing is found (whereas a process is listed if started via command  
prompt).

If I start the backgroundrb script manually at the command prompt and  
then run the cap task to restart it doesn''t give any errors, it stops  
normally (no errors regarding missing process) and appears to restart  
normally. However on inspection you can see there is no process  
running after starting via cap.

No obvious errors are generated in any logs. Has anyone experienced  
anything similar or have any pointers on where to start looking?

Thanks, Andrew.

==backgroundrb.yml=
:backgroundrb:
   :port: 11006
   :ip: 0.0.0.0
   :environment: production
   :persistent_delay: 10

==deploy.rb=
ssh_options[:paranoid] = false
default_run_options[:pty] = true

set :user, ''deploy''
set :runner, ''deploy''
set :use_sudo, false

role :app, "192.168.10.60"
role :web, "192.168.10.60"
role :db,  "192.168.10.60", :primary => true

...

desc "Restart Backgroundrb"
task :restart_backgroundrb, :roles => [:app] do
   run "cd #{current_path} && RAILS_ENV=production
script/backgroundrb
stop"
   run "cd #{current_path} && RAILS_ENV=production
script/backgroundrb
start"
end

==output=
$ cap restart_backgroundrb
   * executing `restart_backgroundrb''
   * executing "cd /var/webapps/optics/current &&
RAILS_ENV=production
script/backgroundrb stop"
     servers: ["192.168.10.60"]
Password:
     [192.168.10.60] executing command
  ** [out :: 192.168.10.60] /var/webapps/optics/releases/ 
20090203095224/vendor/plugins/backgroundrb/lib/backgroundrb/ 
bdrb_start_stop.rb:6:in `getpgid''
  ** [out :: 192.168.10.60] :
  ** [out :: 192.168.10.60] No such process
  ** [out :: 192.168.10.60] (
  ** [out :: 192.168.10.60] Errno::ESRCH
  ** [out :: 192.168.10.60] )
  ** [out :: 192.168.10.60] from /var/webapps/optics/releases/ 
20090203095224/vendor/plugins/backgroundrb/lib/backgroundrb/ 
bdrb_start_stop.rb:6:in `kill_process''
  ** [out :: 192.168.10.60] from /var/webapps/optics/releases/ 
20090203095224/vendor/plugins/backgroundrb/lib/backgroundrb/ 
bdrb_start_stop.rb:56:in `stop''
  ** [out :: 192.168.10.60] from /var/webapps/optics/releases/ 
20090203095224/vendor/plugins/backgroundrb/lib/backgroundrb/ 
bdrb_start_stop.rb:56:in `each''
  ** [out :: 192.168.10.60] from /var/webapps/optics/releases/ 
20090203095224/vendor/plugins/backgroundrb/lib/backgroundrb/ 
bdrb_start_stop.rb:56:in `stop''
  ** [out :: 192.168.10.60] from script/backgroundrb:36
     command finished
failed: "sh -c \"cd /var/webapps/optics/current &&  
RAILS_ENV=production script/backgroundrb stop\"" on 192.168.10.60




-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

For my production environment is use

run "#{deploy_to}/current/script/backgroundrb start -- 
environment=#{environment}\""

Try passing it as a parameter
-Samer Masry
dryBlis


On Feb 7, 2009, at 12:02 AM, andrew at workingtechnology.co.uk wrote:
> Hi,
>
> I have a production environment setup on CentOS 5.2. Latest versions  
> of backgroundrb and associated gems.
>
> When I run script/backgroundrb start directly from the command line  
> on the server is starts fine.
>
> "RAILS_ENV=production script/backgroundrb start"
>
> However the following capistrano task doesn''t seem to work  
> correctly. It creates the pid file containing what looks like a  
> valid id but when looking for the running process with "ps -aux |  
> grep background" nothing is found (whereas a process is listed if  
> started via command prompt).
>
> If I start the backgroundrb script manually at the command prompt  
> and then run the cap task to restart it doesn''t give any errors,
it
> stops normally (no errors regarding missing process) and appears to  
> restart normally. However on inspection you can see there is no  
> process running after starting via cap.
>
> No obvious errors are generated in any logs. Has anyone experienced  
> anything similar or have any pointers on where to start looking?
>
> Thanks, Andrew.
>
> ==backgroundrb.yml=>
> :backgroundrb:
>  :port: 11006
>  :ip: 0.0.0.0
>  :environment: production
>  :persistent_delay: 10
>
> ==deploy.rb=>
> ssh_options[:paranoid] = false
> default_run_options[:pty] = true
>
> set :user, ''deploy''
> set :runner, ''deploy''
> set :use_sudo, false
>
> role :app, "192.168.10.60"
> role :web, "192.168.10.60"
> role :db,  "192.168.10.60", :primary => true
>
> ...
>
> desc "Restart Backgroundrb"
> task :restart_backgroundrb, :roles => [:app] do
>  run "cd #{current_path} && RAILS_ENV=production
script/backgroundrb
> stop"
>  run "cd #{current_path} && RAILS_ENV=production
script/backgroundrb
> start"
> end
>
> ==output=>
> $ cap restart_backgroundrb
>  * executing `restart_backgroundrb''
>  * executing "cd /var/webapps/optics/current &&
RAILS_ENV=production
> script/backgroundrb stop"
>    servers: ["192.168.10.60"]
> Password:
>    [192.168.10.60] executing command
> ** [out :: 192.168.10.60] /var/webapps/optics/releases/ 
> 20090203095224/vendor/plugins/backgroundrb/lib/backgroundrb/ 
> bdrb_start_stop.rb:6:in `getpgid''
> ** [out :: 192.168.10.60] :
> ** [out :: 192.168.10.60] No such process
> ** [out :: 192.168.10.60] (
> ** [out :: 192.168.10.60] Errno::ESRCH
> ** [out :: 192.168.10.60] )
> ** [out :: 192.168.10.60] from /var/webapps/optics/releases/ 
> 20090203095224/vendor/plugins/backgroundrb/lib/backgroundrb/ 
> bdrb_start_stop.rb:6:in `kill_process''
> ** [out :: 192.168.10.60] from /var/webapps/optics/releases/ 
> 20090203095224/vendor/plugins/backgroundrb/lib/backgroundrb/ 
> bdrb_start_stop.rb:56:in `stop''
> ** [out :: 192.168.10.60] from /var/webapps/optics/releases/ 
> 20090203095224/vendor/plugins/backgroundrb/lib/backgroundrb/ 
> bdrb_start_stop.rb:56:in `each''
> ** [out :: 192.168.10.60] from /var/webapps/optics/releases/ 
> 20090203095224/vendor/plugins/backgroundrb/lib/backgroundrb/ 
> bdrb_start_stop.rb:56:in `stop''
> ** [out :: 192.168.10.60] from script/backgroundrb:36
>    command finished
> failed: "sh -c \"cd /var/webapps/optics/current &&  
> RAILS_ENV=production script/backgroundrb stop\"" on 192.168.10.60
>
>
>
>
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
> _______________________________________________
> Backgroundrb-devel mailing list
> Backgroundrb-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/backgroundrb-devel

It looks like the restart of backgroundrb failed to start backgroundrb
because restart''s stop-backgroundrb failed (nothing running, nothing
to stop), and quit the task.

If that''s the case, perhaps a start_backgroundrb task is in order?
I''m
controlling backgroundrb via god, and calling them from capistrano w/
the following task set:

$ cap -T |grep backgroundrb
cap restart_backgroundrb       # restart backgroundrb servers
cap start_backgroundrb         # start backgroundrb servers
cap stop_backgroundrb          # stop backgroundrb servers

# Backgroundrb Server TASKS
%w(start stop restart).each do |cmd|
  desc "#{cmd} backgroundrb servers"
  task "#{cmd}_backgroundrb".to_sym, :roles => :app do
    run "sudo #{god} #{cmd} backgroundrb"
  end
end

hope that helps,
Erik


On 2/7/09, andrew at workingtechnology.co.uk
<andrew at workingtechnology.co.uk> wrote:
> Hi,
>
>  I have a production environment setup on CentOS 5.2. Latest versions of
> backgroundrb and associated gems.
>
>  When I run script/backgroundrb start directly from the command line on the
> server is starts fine.
>
>  "RAILS_ENV=production script/backgroundrb start"
>
>  However the following capistrano task doesn''t seem to work
correctly. It
> creates the pid file containing what looks like a valid id but when looking
> for the running process with "ps -aux | grep background" nothing
is found
> (whereas a process is listed if started via command prompt).
>
>  If I start the backgroundrb script manually at the command prompt and then
> run the cap task to restart it doesn''t give any errors, it stops
normally
> (no errors regarding missing process) and appears to restart normally.
> However on inspection you can see there is no process running after
starting
> via cap.
>
>  No obvious errors are generated in any logs. Has anyone experienced
> anything similar or have any pointers on where to start looking?
>
>  Thanks, Andrew.
>
>  ==backgroundrb.yml=>
>  :backgroundrb:
>   :port: 11006
>   :ip: 0.0.0.0
>   :environment: production
>   :persistent_delay: 10
>
>  ==deploy.rb=>
>  ssh_options[:paranoid] = false
>  default_run_options[:pty] = true
>
>  set :user, ''deploy''
>  set :runner, ''deploy''
>  set :use_sudo, false
>
>  role :app, "192.168.10.60"
>  role :web, "192.168.10.60"
>  role :db,  "192.168.10.60", :primary => true
>
>  ...
>
>  desc "Restart Backgroundrb"
>  task :restart_backgroundrb, :roles => [:app] do
>   run "cd #{current_path} && RAILS_ENV=production
script/backgroundrb stop"
>   run "cd #{current_path} && RAILS_ENV=production
script/backgroundrb start"
>  end
>
>  ==output=>
>  $ cap restart_backgroundrb
>   * executing `restart_backgroundrb''
>   * executing "cd /var/webapps/optics/current &&
RAILS_ENV=production
> script/backgroundrb stop"
>     servers: ["192.168.10.60"]
>  Password:
>     [192.168.10.60] executing command
>   ** [out :: 192.168.10.60]
>
/var/webapps/optics/releases/20090203095224/vendor/plugins/backgroundrb/lib/backgroundrb/bdrb_start_stop.rb:6:in
> `getpgid''
>   ** [out :: 192.168.10.60] :
>   ** [out :: 192.168.10.60] No such process
>   ** [out :: 192.168.10.60] (
>   ** [out :: 192.168.10.60] Errno::ESRCH
>   ** [out :: 192.168.10.60] )
>   ** [out :: 192.168.10.60] from
>
/var/webapps/optics/releases/20090203095224/vendor/plugins/backgroundrb/lib/backgroundrb/bdrb_start_stop.rb:6:in
> `kill_process''
>   ** [out :: 192.168.10.60] from
>
/var/webapps/optics/releases/20090203095224/vendor/plugins/backgroundrb/lib/backgroundrb/bdrb_start_stop.rb:56:in
> `stop''
>   ** [out :: 192.168.10.60] from
>
/var/webapps/optics/releases/20090203095224/vendor/plugins/backgroundrb/lib/backgroundrb/bdrb_start_stop.rb:56:in
> `each''
>   ** [out :: 192.168.10.60] from
>
/var/webapps/optics/releases/20090203095224/vendor/plugins/backgroundrb/lib/backgroundrb/bdrb_start_stop.rb:56:in
> `stop''
>   ** [out :: 192.168.10.60] from script/backgroundrb:36
>     command finished
>  failed: "sh -c \"cd /var/webapps/optics/current &&
RAILS_ENV=production
> script/backgroundrb stop\"" on 192.168.10.60
>
>
>
>
>  --
>  This message has been scanned for viruses and
>  dangerous content by MailScanner, and is
>  believed to be clean.
>
>  _______________________________________________
>  Backgroundrb-devel mailing list
>  Backgroundrb-devel at rubyforge.org
>  http://rubyforge.org/mailman/listinfo/backgroundrb-devel
>

Thanks guys,

I think it might be something to do with the capistrano login session.

If I use essentially the same code as Samer for my cap task:

desc "Start Backgroundrb"
task :start_backgroundrb, :roles => [:app] do
   run "#{deploy_to}/current/script/backgroundrb start -- 
environment=production"
end

I get the following output:

  cap restart_backgroundrb
   * executing `restart_backgroundrb''
   * executing "/var/webapps/optics/current/script/backgroundrb start  
--environment=production"
     servers: ["192.168.10.60"]
Password:
     [192.168.10.60] executing command
  ** [out :: 192.168.10.60] Starting BackgrounDRb ....
     command finished

This updates the pid file with 4488. However look up the pid and  
nothing:

$ ps aux | grep 4488
deploy    4534  0.0  0.0   3924   680 pts/1    S+   10:30   0:00 grep  
4488

If however I run the cap task''s run command by hand on the server via  
a normal ssh session (same user, "deploy") the pid generated actually
refers
to a running process:

$script/backgroundrb start --environment=production

$ps aux | grep 5080
deploy    5080  0.6  1.6  57536 51088 pts/1    S    10:44   0:00 ruby  
script/backgroundrb start --environment=production
deploy    5089  0.0  0.0   3920   676 pts/1    S+   10:44   0:00 grep  
background

I guess there is something specific about the cap session that is  
different to a regular ssh. If I can''t find a solution, as suggested I
suppose I could use god/monit to restart the process locally and just  
use the cap task to stop the backgroundrb process, which it doesn''t  
seem to have a problem with unlike starting.

Thanks for your help, Andrew.

On 7 Feb 2009, at 16:49, E. Johnson wrote:
> It looks like the restart of backgroundrb failed to start backgroundrb
> because restart''s stop-backgroundrb failed (nothing running,
nothing
> to stop), and quit the task.
>
> If that''s the case, perhaps a start_backgroundrb task is in order?
I''m
> controlling backgroundrb via god, and calling them from capistrano w/
> the following task set:
>
> $ cap -T |grep backgroundrb
> cap restart_backgroundrb       # restart backgroundrb servers
> cap start_backgroundrb         # start backgroundrb servers
> cap stop_backgroundrb          # stop backgroundrb servers
>
> # Backgroundrb Server TASKS
> %w(start stop restart).each do |cmd|
>  desc "#{cmd} backgroundrb servers"
>  task "#{cmd}_backgroundrb".to_sym, :roles => :app do
>    run "sudo #{god} #{cmd} backgroundrb"
>  end
> end
>
> hope that helps,
> Erik
>



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Hi,

You are correct.  This topic''s instructions might help:

http://kete.net.nz/documentation/topics/show/240-configuring-sudo-path-in-capistrano-deployments

We use backgroundrb as a part of Kete, an open source Rails app and  
were running into issues with starting/stopping and gem installs.

Cheers,
Walter

On Feb 8, 2009, at 11:56 PM, andrew at workingtechnology.co.uk wrote:
> Thanks guys,
>
> I think it might be something to do with the capistrano login session.
>
> If I use essentially the same code as Samer for my cap task:
>
> desc "Start Backgroundrb"
> task :start_backgroundrb, :roles => [:app] do
>  run "#{deploy_to}/current/script/backgroundrb start -- 
> environment=production"
> end
>
> I get the following output:
>
> cap restart_backgroundrb
>  * executing `restart_backgroundrb''
>  * executing "/var/webapps/optics/current/script/backgroundrb start  
> --environment=production"
>    servers: ["192.168.10.60"]
> Password:
>    [192.168.10.60] executing command
> ** [out :: 192.168.10.60] Starting BackgrounDRb ....
>    command finished
>
> This updates the pid file with 4488. However look up the pid and  
> nothing:
>
> $ ps aux | grep 4488
> deploy    4534  0.0  0.0   3924   680 pts/1    S+   10:30   0:00  
> grep 4488
>
> If however I run the cap task''s run command by hand on the server
> via a normal ssh session (same user, "deploy") the pid generated
> actually refers
> to a running process:
>
> $script/backgroundrb start --environment=production
>
> $ps aux | grep 5080
> deploy    5080  0.6  1.6  57536 51088 pts/1    S    10:44   0:00  
> ruby script/backgroundrb start --environment=production
> deploy    5089  0.0  0.0   3920   676 pts/1    S+   10:44   0:00  
> grep background
>
> I guess there is something specific about the cap session that is  
> different to a regular ssh. If I can''t find a solution, as
suggested
> I suppose I could use god/monit to restart the process locally and  
> just use the cap task to stop the backgroundrb process, which it  
> doesn''t seem to have a problem with unlike starting.
>
> Thanks for your help, Andrew.
>
> On 7 Feb 2009, at 16:49, E. Johnson wrote:
>
>> It looks like the restart of backgroundrb failed to start  
>> backgroundrb
>> because restart''s stop-backgroundrb failed (nothing running,
nothing
>> to stop), and quit the task.
>>
>> If that''s the case, perhaps a start_backgroundrb task is in
order?
>> I''m
>> controlling backgroundrb via god, and calling them from capistrano w/
>> the following task set:
>>
>> $ cap -T |grep backgroundrb
>> cap restart_backgroundrb       # restart backgroundrb servers
>> cap start_backgroundrb         # start backgroundrb servers
>> cap stop_backgroundrb          # stop backgroundrb servers
>>
>> # Backgroundrb Server TASKS
>> %w(start stop restart).each do |cmd|
>> desc "#{cmd} backgroundrb servers"
>> task "#{cmd}_backgroundrb".to_sym, :roles => :app do
>>   run "sudo #{god} #{cmd} backgroundrb"
>> end
>> end
>>
>> hope that helps,
>> Erik
>>
>
>
>
>
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
> _______________________________________________
> Backgroundrb-devel mailing list
> Backgroundrb-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/backgroundrb-devel

Is there anything set in your profile that you are specifying.

There are a few things to capistrano.  First off it uses ssh and ssh  
when it''s compiled has  a PATH variable that is hard coded.  If you  
are using a version of ruby that is not in ssh''s default path it
wont''
work.  If there is anything that is specified in you .profile  
or .bash_profile you may want to source your profile before you  
execute your command

run ". ~/.bash_profile; #{command}"


-Samer
dryBlis

On Feb 8, 2009, at 2:56 AM, andrew at workingtechnology.co.uk wrote:
> Thanks guys,
>
> I think it might be something to do with the capistrano login session.
>
> If I use essentially the same code as Samer for my cap task:
>
> desc "Start Backgroundrb"
> task :start_backgroundrb, :roles => [:app] do
>  run "#{deploy_to}/current/script/backgroundrb start -- 
> environment=production"
> end
>
> I get the following output:
>
> cap restart_backgroundrb
>  * executing `restart_backgroundrb''
>  * executing "/var/webapps/optics/current/script/backgroundrb start  
> --environment=production"
>    servers: ["192.168.10.60"]
> Password:
>    [192.168.10.60] executing command
> ** [out :: 192.168.10.60] Starting BackgrounDRb ....
>    command finished
>
> This updates the pid file with 4488. However look up the pid and  
> nothing:
>
> $ ps aux | grep 4488
> deploy    4534  0.0  0.0   3924   680 pts/1    S+   10:30   0:00  
> grep 4488
>
> If however I run the cap task''s run command by hand on the server
> via a normal ssh session (same user, "deploy") the pid generated
> actually refers
> to a running process:
>
> $script/backgroundrb start --environment=production
>
> $ps aux | grep 5080
> deploy    5080  0.6  1.6  57536 51088 pts/1    S    10:44   0:00  
> ruby script/backgroundrb start --environment=production
> deploy    5089  0.0  0.0   3920   676 pts/1    S+   10:44   0:00  
> grep background
>
> I guess there is something specific about the cap session that is  
> different to a regular ssh. If I can''t find a solution, as
suggested
> I suppose I could use god/monit to restart the process locally and  
> just use the cap task to stop the backgroundrb process, which it  
> doesn''t seem to have a problem with unlike starting.
>
> Thanks for your help, Andrew.
>
> On 7 Feb 2009, at 16:49, E. Johnson wrote:
>
>> It looks like the restart of backgroundrb failed to start  
>> backgroundrb
>> because restart''s stop-backgroundrb failed (nothing running,
nothing
>> to stop), and quit the task.
>>
>> If that''s the case, perhaps a start_backgroundrb task is in
order?
>> I''m
>> controlling backgroundrb via god, and calling them from capistrano w/
>> the following task set:
>>
>> $ cap -T |grep backgroundrb
>> cap restart_backgroundrb       # restart backgroundrb servers
>> cap start_backgroundrb         # start backgroundrb servers
>> cap stop_backgroundrb          # stop backgroundrb servers
>>
>> # Backgroundrb Server TASKS
>> %w(start stop restart).each do |cmd|
>> desc "#{cmd} backgroundrb servers"
>> task "#{cmd}_backgroundrb".to_sym, :roles => :app do
>>   run "sudo #{god} #{cmd} backgroundrb"
>> end
>> end
>>
>> hope that helps,
>> Erik
>>
>
>
>
>
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
> _______________________________________________
> Backgroundrb-devel mailing list
> Backgroundrb-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/backgroundrb-devel

Thanks, really appreciate taking the time to help me out.

I think I''ve worked it out though with a little help from
https://gist.github.com/raw/21559/4a8d70c1c3f7874cd435be59a5ed89a6003284a4/deploy.rb

As my deploy.rb file includes "default_run_options[:pty] = true" the  
run commands are executed via a pseudo-tty. It seems that you can''t  
start a daemon process in this without it stopping on hangup  
(disconnect), at least not on CentOS - can''t say for certain on others
although I would imagine so.

If however you prepend the run command with nohup everything works  
correctly and the process stays running after the cap session ends. I  
now have:

run "nohup #{deploy_to}/current/script/backgroundrb start -- 
environment=production"

Incidentally, if you take "default_run_options[:pty] = true" out of  
deploy.rb the backgroundrb start command doesn''t return and locks the  
session. Jamis Buck briefly covers this here:
http://weblog.jamisbuck.org/2007/10/14/capistrano-2-1

Thanks again, Andrew.

On 8 Feb 2009, at 17:47, Walter McGinnis wrote:
> Hi,
>
> You are correct.  This topic''s instructions might help:
>
>
http://kete.net.nz/documentation/topics/show/240-configuring-sudo-path-in-capistrano-deployments
>
> We use backgroundrb as a part of Kete, an open source Rails app and  
> were running into issues with starting/stopping and gem installs.
>
> Cheers,
> Walter
>
> On Feb 8, 2009, at 11:56 PM, andrew at workingtechnology.co.uk wrote:
>
>> Thanks guys,
>>
>> I think it might be something to do with the capistrano login  
>> session.
>>
>> If I use essentially the same code as Samer for my cap task:
>>
>> desc "Start Backgroundrb"
>> task :start_backgroundrb, :roles => [:app] do
>> run "#{deploy_to}/current/script/backgroundrb start -- 
>> environment=production"
>> end
>>
>> I get the following output:
>>
>> cap restart_backgroundrb
>> * executing `restart_backgroundrb''
>> * executing "/var/webapps/optics/current/script/backgroundrb start
>> --environment=production"
>>   servers: ["192.168.10.60"]
>> Password:
>>   [192.168.10.60] executing command
>> ** [out :: 192.168.10.60] Starting BackgrounDRb ....
>>   command finished
>>
>> This updates the pid file with 4488. However look up the pid and  
>> nothing:
>>
>> $ ps aux | grep 4488
>> deploy    4534  0.0  0.0   3924   680 pts/1    S+   10:30   0:00  
>> grep 4488
>>
>> If however I run the cap task''s run command by hand on the
server
>> via a normal ssh session (same user, "deploy") the pid
generated
>> actually refers
>> to a running process:
>>
>> $script/backgroundrb start --environment=production
>>
>> $ps aux | grep 5080
>> deploy    5080  0.6  1.6  57536 51088 pts/1    S    10:44   0:00  
>> ruby script/backgroundrb start --environment=production
>> deploy    5089  0.0  0.0   3920   676 pts/1    S+   10:44   0:00  
>> grep background
>>
>> I guess there is something specific about the cap session that is  
>> different to a regular ssh. If I can''t find a solution, as  
>> suggested I suppose I could use god/monit to restart the process  
>> locally and just use the cap task to stop the backgroundrb process,  
>> which it doesn''t seem to have a problem with unlike starting.
>>
>> Thanks for your help, Andrew.
>>
>> On 7 Feb 2009, at 16:49, E. Johnson wrote:
>>
>>> It looks like the restart of backgroundrb failed to start  
>>> backgroundrb
>>> because restart''s stop-backgroundrb failed (nothing
running, nothing
>>> to stop), and quit the task.
>>>
>>> If that''s the case, perhaps a start_backgroundrb task is
in order?
>>> I''m
>>> controlling backgroundrb via god, and calling them from capistrano
>>> w/
>>> the following task set:
>>>
>>> $ cap -T |grep backgroundrb
>>> cap restart_backgroundrb       # restart backgroundrb servers
>>> cap start_backgroundrb         # start backgroundrb servers
>>> cap stop_backgroundrb          # stop backgroundrb servers
>>>
>>> # Backgroundrb Server TASKS
>>> %w(start stop restart).each do |cmd|
>>> desc "#{cmd} backgroundrb servers"
>>> task "#{cmd}_backgroundrb".to_sym, :roles => :app do
>>>  run "sudo #{god} #{cmd} backgroundrb"
>>> end
>>> end
>>>
>>> hope that helps,
>>> Erik
>>>
>>
>>
>>
>>
>> -- 
>> This message has been scanned for viruses and
>> dangerous content by MailScanner, and is
>> believed to be clean.
>>
>> _______________________________________________
>> 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
>
>
>
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.