Backgroundrb devel - Mar 2007 - Capistrano Hanging on Deployment

Hello ~

I am using the Capistrano recipe outlined in this post to restart my
backgroundrb server:

http://rubyforge.org/pipermail/backgroundrb-devel/2007-February/000718.html

My Version:
~~~~~~~~~~~~
task :before_restart, :roles => :app do
   restart_backgroundrb
end

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

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

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

The backgroundrb server is stopped and started but hangs at the
start_backgroundrb task.  Capistrano shows:

  * executing task start_backgroundrb
  * executing "sudo  nohup
/var/www/rails/*************/current/script/backgroundrb/start"
    servers: ["host"]
    [host] executing command
 ** [out :: host] nohup: ignoring input and appending output to
`nohup.out''

It will hang there and not restart the main web app process.  I updated my
gems to see if this was a version issue, but am experiencing the same
problem.  I also tried running this task :after_restart, the web app is
successfully restarted, but it still hangs.

Thanks in advance for any ideas on how to fix this.

~ Ben

-- 
Ben Reubenstein
303-947-0446
http://www.benr75.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20070312/3f321843/attachment.html

Yeah there are some weird interactions between capistrano and some  
daemons, the old version of backgroundrb exibits this behavior. That  
way I get around it is by creating an init.d script, then letting  
capuse that to restart bdrb. Works like a charm. Here is an init.d  
script for Gentoo systems, it should be easy to adapt to any other  
unixy system.:

#!/sbin/runscript
# Copyright 1999-2004 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/www-servers/nginx/files/nginx-r1,v  
1.1 2006/07/04 16:58:38 voxus Exp $


depend() {
         need net
         use dns
         after gfs
}
start() {
         ebegin "Starting bdrb2"
           RAILS_ENV=demo /data/toolbox/current/script/backgroundrb/ 
start -d
         eend $? "Failed to start bdrb2"
}

stop() {
         ebegin "Stopping bdrb2"
              kill -9 `cat /data/toolbox/current/log/ 
backgroundrb.pid` 2>/dev/null; true
         eend $? "Failed to stop bdrb2"
}



Cheers-
-Ezra


On Mar 12, 2007, at 10:47 AM, Ben Reubenstein wrote:
> Hello ~
>
> I am using the Capistrano recipe outlined in this post to restart  
> my backgroundrb server:
>
> http://rubyforge.org/pipermail/backgroundrb-devel/2007-February/ 
> 000718.html
>
> My Version:
> ~~~~~~~~~~~~
> task :before_restart, :roles => :app do
>    restart_backgroundrb
> end
>
> task :start_backgroundrb, :roles => :app do
>    sudo "nohup /var/www/rails/#{application}/current/script/ 
> backgroundrb/start "
> end
>
> task :stop_backgroundrb, :roles => :app do
>    sudo "kill -9 `cat /var/www/rails/#{application}/current/log/ 
> backgroundrb.pid` 2>/dev/null; true"
> end
>
> task :restart_backgroundrb, :roles => :app do
>    stop_backgroundrb
>    start_backgroundrb
> end
> ~~~~~~~~~~~~
>
> The backgroundrb server is stopped and started but hangs at the  
> start_backgroundrb task.  Capistrano shows:
>
>   * executing task start_backgroundrb
>   * executing "sudo  nohup /var/www/rails/*************/current/ 
> script/backgroundrb/start"
>     servers: ["host"]
>     [host] executing command
>  ** [out :: host] nohup: ignoring input and appending output to  
> `nohup.out''
>
> It will hang there and not restart the main web app process.  I  
> updated my gems to see if this was a version issue, but am  
> experiencing the same problem.  I also tried running this  
> task :after_restart, the web app is successfully restarted, but it  
> still hangs.
>
> Thanks in advance for any ideas on how to fix this.
>
> ~ Ben
>
> -- 
> Ben Reubenstein
> 303-947-0446
> http://www.benr75.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)

Fantastic!  This approach worked well and was easy for me to implement as my
production servers run Gentoo.

Thx!

~ Ben

On 3/12/07, Ezra Zygmuntowicz <ezmobius at gmail.com>
wrote:
>
>
>         Yeah there are some weird interactions between capistrano and some
> daemons, the old version of backgroundrb exibits this behavior. That
> way I get around it is by creating an init.d script, then letting
> capuse that to restart bdrb. Works like a charm. Here is an init.d
> script for Gentoo systems, it should be easy to adapt to any other
> unixy system.:
>
> #!/sbin/runscript
> # Copyright 1999-2004 Gentoo Foundation
> # Distributed under the terms of the GNU General Public License v2
> # $Header: /var/cvsroot/gentoo-x86/www-servers/nginx/files/nginx-r1,v
> 1.1 2006/07/04 16:58:38 voxus Exp $
>
>
> depend() {
>          need net
>          use dns
>          after gfs
> }
> start() {
>          ebegin "Starting bdrb2"
>            RAILS_ENV=demo /data/toolbox/current/script/backgroundrb/
> start -d
>          eend $? "Failed to start bdrb2"
> }
>
> stop() {
>          ebegin "Stopping bdrb2"
>               kill -9 `cat /data/toolbox/current/log/
> backgroundrb.pid` 2>/dev/null; true
>          eend $? "Failed to stop bdrb2"
> }
>
>
>
> Cheers-
> -Ezra
>
>
> On Mar 12, 2007, at 10:47 AM, Ben Reubenstein wrote:
>
> > Hello ~
> >
> > I am using the Capistrano recipe outlined in this post to restart
> > my backgroundrb server:
> >
> > http://rubyforge.org/pipermail/backgroundrb-devel/2007-February/
> > 000718.html
> >
> > My Version:
> > ~~~~~~~~~~~~
> > task :before_restart, :roles => :app do
> >    restart_backgroundrb
> > end
> >
> > task :start_backgroundrb, :roles => :app do
> >    sudo "nohup /var/www/rails/#{application}/current/script/
> > backgroundrb/start "
> > end
> >
> > task :stop_backgroundrb, :roles => :app do
> >    sudo "kill -9 `cat /var/www/rails/#{application}/current/log/
> > backgroundrb.pid` 2>/dev/null; true"
> > end
> >
> > task :restart_backgroundrb, :roles => :app do
> >    stop_backgroundrb
> >    start_backgroundrb
> > end
> > ~~~~~~~~~~~~
> >
> > The backgroundrb server is stopped and started but hangs at the
> > start_backgroundrb task.  Capistrano shows:
> >
> >   * executing task start_backgroundrb
> >   * executing "sudo  nohup /var/www/rails/*************/current/
> > script/backgroundrb/start"
> >     servers: ["host"]
> >     [host] executing command
> >  ** [out :: host] nohup: ignoring input and appending output to
> > `nohup.out''
> >
> > It will hang there and not restart the main web app process.  I
> > updated my gems to see if this was a version issue, but am
> > experiencing the same problem.  I also tried running this
> > task :after_restart, the web app is successfully restarted, but it
> > still hangs.
> >
> > Thanks in advance for any ideas on how to fix this.
> >
> > ~ Ben
> >
> > --
> > Ben Reubenstein
> > 303-947-0446
> > http://www.benr75.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)
>
>
>

-- 
Ben Reubenstein
303-947-0446
http://www.benr75.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20070312/5080cb83/attachment.html

Erza,

I am on Centos and bash, Rails 1.2.2, Ruby 1.8.4, BackgrounDrb old version
(the 0.1.x version right before 0.2...  Is the depend() section peculiar
only to Gentoo?  If not, anything one needs to do for this?

I wrote a script just similar to this (w/o paying attention to the depend()
section) and have capistrano before_restart task invoke the
"/etc/init.d/backgroundrbd restart" (which is just stop and then
start).
However, this problem of backgroundrb''s exiting after cap
task''s successful
completion occurs (yes, no hanging in cap''s process, but backgroundrb
quits
even though it is started in -d mode; the pid log file is there, but the
process is no longer).  Prepending with "nohup" in start seems to
work, but
I thought by using init.d style, one needn''t worry about the nohup
problem,
either.  Any insight?  (Or is this a 0.1.x problem?)

Thanks,
Philip

On 3/12/07, Ezra Zygmuntowicz <ezmobius at gmail.com>
wrote:
>
>
>         Yeah there are some weird interactions between capistrano and some
> daemons, the old version of backgroundrb exibits this behavior. That
> way I get around it is by creating an init.d script, then letting
> capuse that to restart bdrb. Works like a charm. Here is an init.d
> script for Gentoo systems, it should be easy to adapt to any other
> unixy system.:
>
> #!/sbin/runscript
> # Copyright 1999-2004 Gentoo Foundation
> # Distributed under the terms of the GNU General Public License v2
> # $Header: /var/cvsroot/gentoo-x86/www-servers/nginx/files/nginx-r1,v
> 1.1 2006/07/04 16:58:38 voxus Exp $
>
>
> depend() {
>          need net
>          use dns
>          after gfs
> }
> start() {
>          ebegin "Starting bdrb2"
>            RAILS_ENV=demo /data/toolbox/current/script/backgroundrb/
> start -d
>          eend $? "Failed to start bdrb2"
> }
>
> stop() {
>          ebegin "Stopping bdrb2"
>               kill -9 `cat /data/toolbox/current/log/
> backgroundrb.pid` 2>/dev/null; true
>          eend $? "Failed to stop bdrb2"
> }
>
>
>
> Cheers-
> -Ezra
>
>
> On Mar 12, 2007, at 10:47 AM, Ben Reubenstein wrote:
>
> > Hello ~
> >
> > I am using the Capistrano recipe outlined in this post to restart
> > my backgroundrb server:
> >
> > http://rubyforge.org/pipermail/backgroundrb-devel/2007-February/
> > 000718.html
> >
> > My Version:
> > ~~~~~~~~~~~~
> > task :before_restart, :roles => :app do
> >    restart_backgroundrb
> > end
> >
> > task :start_backgroundrb, :roles => :app do
> >    sudo "nohup /var/www/rails/#{application}/current/script/
> > backgroundrb/start "
> > end
> >
> > task :stop_backgroundrb, :roles => :app do
> >    sudo "kill -9 `cat /var/www/rails/#{application}/current/log/
> > backgroundrb.pid` 2>/dev/null; true"
> > end
> >
> > task :restart_backgroundrb, :roles => :app do
> >    stop_backgroundrb
> >    start_backgroundrb
> > end
> > ~~~~~~~~~~~~
> >
> > The backgroundrb server is stopped and started but hangs at the
> > start_backgroundrb task.  Capistrano shows:
> >
> >   * executing task start_backgroundrb
> >   * executing "sudo  nohup /var/www/rails/*************/current/
> > script/backgroundrb/start"
> >     servers: ["host"]
> >     [host] executing command
> >  ** [out :: host] nohup: ignoring input and appending output to
> > `nohup.out''
> >
> > It will hang there and not restart the main web app process.  I
> > updated my gems to see if this was a version issue, but am
> > experiencing the same problem.  I also tried running this
> > task :after_restart, the web app is successfully restarted, but it
> > still hangs.
> >
> > Thanks in advance for any ideas on how to fix this.
> >
> > ~ Ben
> >
> > --
> > Ben Reubenstein
> > 303-947-0446
> > http://www.benr75.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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20070315/34996eb2/attachment.html

Hi Philip ~

I am having this issue too and have been meaning to post.  I am using the
init script on Gentoo, and it works perfectly if I am in the machine but
when running from capistrano it will report a successful start/stop but the
process is nowhere to be found.  I have to login to the machine and start it
manually.  I am running on the latest version so I don''t think it is a
backgroundrb version issue.

~ Ben

On 3/15/07, Philip Lipu Tsai <tsailipu at gmail.com>
wrote:
>
> Erza,
>
> I am on Centos and bash, Rails 1.2.2, Ruby 1.8.4, BackgrounDrb old version
> (the 0.1.x version right before 0.2...  Is the depend() section peculiar
> only to Gentoo?  If not, anything one needs to do for this?
>
> I wrote a script just similar to this (w/o paying attention to the
> depend() section) and have capistrano before_restart task invoke the
> "/etc/init.d/backgroundrbd restart" (which is just stop and then
start).
> However, this problem of backgroundrb''s exiting after cap
task''s successful
> completion occurs (yes, no hanging in cap''s process, but
backgroundrb quits
> even though it is started in -d mode; the pid log file is there, but the
> process is no longer).  Prepending with "nohup" in start seems to
work, but
> I thought by using init.d style, one needn''t worry about the nohup
> problem, either.  Any insight?  (Or is this a 0.1.x problem?)
>
> Thanks,
> Philip
>
> On 3/12/07, Ezra Zygmuntowicz <ezmobius at gmail.com> wrote:
> >
> >
> >         Yeah there are some weird interactions between capistrano and
> > some
> > daemons, the old version of backgroundrb exibits this behavior. That
> > way I get around it is by creating an init.d script, then letting
> > capuse that to restart bdrb. Works like a charm. Here is an init.d
> > script for Gentoo systems, it should be easy to adapt to any other
> > unixy system.:
> >
> > #!/sbin/runscript
> > # Copyright 1999-2004 Gentoo Foundation
> > # Distributed under the terms of the GNU General Public License v2
> > # $Header: /var/cvsroot/gentoo-x86/www-servers/nginx/files/nginx-r1,v
> > 1.1 2006/07/04 16:58:38 voxus Exp $
> >
> >
> > depend() {
> >          need net
> >          use dns
> >          after gfs
> > }
> > start() {
> >          ebegin "Starting bdrb2"
> >            RAILS_ENV=demo /data/toolbox/current/script/backgroundrb/
> > start -d
> >          eend $? "Failed to start bdrb2"
> > }
> >
> > stop() {
> >          ebegin "Stopping bdrb2"
> >               kill -9 `cat /data/toolbox/current/log/
> > backgroundrb.pid` 2>/dev/null; true
> >          eend $? "Failed to stop bdrb2"
> > }
> >
> >
> >
> > Cheers-
> > -Ezra
> >
> >
> > On Mar 12, 2007, at 10:47 AM, Ben Reubenstein wrote:
> >
> > > Hello ~
> > >
> > > I am using the Capistrano recipe outlined in this post to restart
> > > my backgroundrb server:
> > >
> > > http://rubyforge.org/pipermail/backgroundrb-devel/2007-February/
> > > 000718.html
> > >
> > > My Version:
> > > ~~~~~~~~~~~~
> > > task :before_restart, :roles => :app do
> > >    restart_backgroundrb
> > > end
> > >
> > > task :start_backgroundrb, :roles => :app do
> > >    sudo "nohup /var/www/rails/#{application}/current/script/
> > > backgroundrb/start "
> > > end
> > >
> > > task :stop_backgroundrb, :roles => :app do
> > >    sudo "kill -9 `cat
/var/www/rails/#{application}/current/log/
> > > backgroundrb.pid` 2>/dev/null; true"
> > > end
> > >
> > > task :restart_backgroundrb, :roles => :app do
> > >    stop_backgroundrb
> > >    start_backgroundrb
> > > end
> > > ~~~~~~~~~~~~
> > >
> > > The backgroundrb server is stopped and started but hangs at the
> > > start_backgroundrb task.  Capistrano shows:
> > >
> > >   * executing task start_backgroundrb
> > >   * executing "sudo  nohup
/var/www/rails/*************/current/
> > > script/backgroundrb/start"
> > >     servers: ["host"]
> > >     [host] executing command
> > >  ** [out :: host] nohup: ignoring input and appending output to
> > > `nohup.out''
> > >
> > > It will hang there and not restart the main web app process.  I
> > > updated my gems to see if this was a version issue, but am
> > > experiencing the same problem.  I also tried running this
> > > task :after_restart, the web app is successfully restarted, but
it
> > > still hangs.
> > >
> > > Thanks in advance for any ideas on how to fix this.
> > >
> > > ~ Ben
> > >
> > > --
> > > Ben Reubenstein
> > > 303-947-0446
> > > http://www.benr75.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
>


-- 
Ben Reubenstein
303-947-0446
http://www.benr75.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20070316/e7ad6bf3/attachment.html

Hello Ben,

Erza and you are on Gentoo -- so I thought Erza''s script would work on
Gentoo.  Looks like your try didn''t work there, either(?)  Because I am
on
Centos, based on RedHat, I thought there may be some minor differences (the
only difference being the depend section that I don''t know how to
translate.. well, unless I spend more time looking into it.).  So I tried
putting nohup as such: "RAILS_ENV=production nohup
/etc/init.d/backgroundrbd
start -d" and it worked.  Though it worked, this combination of nohup
inside
init.d looked a bit unusual (btw, I don''t know if setting this
RAILS_ENV
this way is still necessary for 0.2.x -- it''s a weird artifact/bug), so
I am
curious to see whether Erza or anyone here knows what''s up.  There must
be
quite some number of people using backgroundrb and quite some serious about
deployment and use capistrano....  So, I hope that we get to discover
something more here.  ;)

On 3/16/07, Ben Reubenstein <benr at x-cr.com>
wrote:
>
> Hi Philip ~
>
> I am having this issue too and have been meaning to post.  I am using the
> init script on Gentoo, and it works perfectly if I am in the machine but
> when running from capistrano it will report a successful start/stop but the
> process is nowhere to be found.  I have to login to the machine and start
it
> manually.  I am running on the latest version so I don''t think it
is a
> backgroundrb version issue.
>
> ~ Ben
>
> On 3/15/07, Philip Lipu Tsai <tsailipu at gmail.com> wrote:
> >
> > Erza,
> >
> > I am on Centos and bash, Rails 1.2.2, Ruby 1.8.4, BackgrounDrb old
> > version (the 0.1.x version right before 0.2...  Is the depend()
section
> > peculiar only to Gentoo?  If not, anything one needs to do for this?
> >
> > I wrote a script just similar to this (w/o paying attention to the
> > depend() section) and have capistrano before_restart task invoke the
> > "/etc/init.d/backgroundrbd restart" (which is just stop and
then start).
> > However, this problem of backgroundrb''s exiting after cap
task''s successful
> > completion occurs (yes, no hanging in cap''s process, but
backgroundrb quits
> > even though it is started in -d mode; the pid log file is there, but
the
> > process is no longer).  Prepending with "nohup" in start
seems to work, but
> > I thought by using init.d style, one needn''t worry about the
nohup
> > problem, either.  Any insight?  (Or is this a 0.1.x problem?)
> >
> > Thanks,
> > Philip
> >
> > On 3/12/07, Ezra Zygmuntowicz <ezmobius at gmail.com> wrote:
> > >
> > >
> > >         Yeah there are some weird interactions between capistrano
and
> > > some
> > > daemons, the old version of backgroundrb exibits this behavior.
That
> > > way I get around it is by creating an init.d script, then letting
> > > capuse that to restart bdrb. Works like a charm. Here is an
init.d
> > > script for Gentoo systems, it should be easy to adapt to any
other
> > > unixy system.:
> > >
> > > #!/sbin/runscript
> > > # Copyright 1999-2004 Gentoo Foundation
> > > # Distributed under the terms of the GNU General Public License
v2
> > > # $Header:
/var/cvsroot/gentoo-x86/www-servers/nginx/files/nginx-r1,v
> > > 1.1 2006/07/04 16:58:38 voxus Exp $
> > >
> > >
> > > depend() {
> > >          need net
> > >          use dns
> > >          after gfs
> > > }
> > > start() {
> > >          ebegin "Starting bdrb2"
> > >            RAILS_ENV=demo
/data/toolbox/current/script/backgroundrb/
> > > start -d
> > >          eend $? "Failed to start bdrb2"
> > > }
> > >
> > > stop() {
> > >          ebegin "Stopping bdrb2"
> > >               kill -9 `cat /data/toolbox/current/log/
> > > backgroundrb.pid` 2>/dev/null; true
> > >          eend $? "Failed to stop bdrb2"
> > > }
> > >
> > >
> > >
> > > Cheers-
> > > -Ezra
> > >
> > >
> > > On Mar 12, 2007, at 10:47 AM, Ben Reubenstein wrote:
> > >
> > > > Hello ~
> > > >
> > > > I am using the Capistrano recipe outlined in this post to
restart
> > > > my backgroundrb server:
> > > >
> > > >
http://rubyforge.org/pipermail/backgroundrb-devel/2007-February/
> > > > 000718.html
> > > >
> > > > My Version:
> > > > ~~~~~~~~~~~~
> > > > task :before_restart, :roles => :app do
> > > >    restart_backgroundrb
> > > > end
> > > >
> > > > task :start_backgroundrb, :roles => :app do
> > > >    sudo "nohup
/var/www/rails/#{application}/current/script/
> > > > backgroundrb/start "
> > > > end
> > > >
> > > > task :stop_backgroundrb, :roles => :app do
> > > >    sudo "kill -9 `cat
/var/www/rails/#{application}/current/log/
> > > > backgroundrb.pid` 2>/dev/null; true"
> > > > end
> > > >
> > > > task :restart_backgroundrb, :roles => :app do
> > > >    stop_backgroundrb
> > > >    start_backgroundrb
> > > > end
> > > > ~~~~~~~~~~~~
> > > >
> > > > The backgroundrb server is stopped and started but hangs at
the
> > > > start_backgroundrb task.  Capistrano shows:
> > > >
> > > >   * executing task start_backgroundrb
> > > >   * executing "sudo  nohup
/var/www/rails/*************/current/
> > > > script/backgroundrb/start"
> > > >     servers: ["host"]
> > > >     [host] executing command
> > > >  ** [out :: host] nohup: ignoring input and appending output
to
> > > > `nohup.out''
> > > >
> > > > It will hang there and not restart the main web app process.
I
> > > > updated my gems to see if this was a version issue, but am
> > > > experiencing the same problem.  I also tried running this
> > > > task :after_restart, the web app is successfully restarted,
but it
> > > > still hangs.
> > > >
> > > > Thanks in advance for any ideas on how to fix this.
> > > >
> > > > ~ Ben
> > > >
> > > > --
> > > > Ben Reubenstein
> > > > 303-947-0446
> > > > http://www.benr75.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
> >
>
>
>
> --
> Ben Reubenstein
> 303-947-0446
> http://www.benr75.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20070316/ba2274fa/attachment-0001.html

Typo -- clarifying here for future newcomers, though experienced eyes
probably caught this already:

That command that I put inside init.d was: "RAILS_ENV=production nohup
/[path to my app]/current/script/backgroudrb/start -d"  (one
doesn''t really
put "/etc/init.d/[script name] -d" inside the script itself. ;)

On 3/16/07, Philip Lipu Tsai <tsailipu at gmail.com>
wrote:
>
> Hello Ben,
>
> Erza and you are on Gentoo -- so I thought Erza''s script would
work on
> Gentoo.  Looks like your try didn''t work there, either(?)  Because
I am on
> Centos, based on RedHat, I thought there may be some minor differences (the
> only difference being the depend section that I don''t know how to
> translate.. well, unless I spend more time looking into it.).  So I tried
> putting nohup as such: "RAILS_ENV=production nohup
/etc/init.d/backgroundrbd
> start -d" and it worked.  Though it worked, this combination of nohup
inside
> init.d looked a bit unusual (btw, I don''t know if setting this
RAILS_ENV
> this way is still necessary for 0.2.x -- it''s a weird
artifact/bug), so I
> am curious to see whether Erza or anyone here knows what''s up. 
There must
> be quite some number of people using backgroundrb and quite some serious
> about deployment and use capistrano....  So, I hope that we get to discover
> something more here.  ;)
>
> On 3/16/07, Ben Reubenstein <benr at x-cr.com> wrote:
> >
> > Hi Philip ~
> >
> > I am having this issue too and have been meaning to post.  I am using
> > the init script on Gentoo, and it works perfectly if I am in the
machine but
> > when running from capistrano it will report a successful start/stop
but the
> > process is nowhere to be found.  I have to login to the machine and
start it
> > manually.  I am running on the latest version so I don''t
think it is a
> > backgroundrb version issue.
> >
> > ~ Ben
> >
> > On 3/15/07, Philip Lipu Tsai < tsailipu at gmail.com> wrote:
> > >
> > > Erza,
> > >
> > > I am on Centos and bash, Rails 1.2.2, Ruby 1.8.4, BackgrounDrb
old
> > > version (the 0.1.x version right before 0.2...  Is the depend()
> > > section peculiar only to Gentoo?  If not, anything one needs to
do for this?
> > >
> > >
> > > I wrote a script just similar to this (w/o paying attention to
the
> > > depend() section) and have capistrano before_restart task invoke
the
> > > "/etc/init.d/backgroundrbd restart" (which is just stop
and then start).
> > > However, this problem of backgroundrb''s exiting after
cap task''s successful
> > > completion occurs (yes, no hanging in cap''s process, but
backgroundrb quits
> > > even though it is started in -d mode; the pid log file is there,
but the
> > > process is no longer).  Prepending with "nohup" in
start seems to work, but
> > > I thought by using init.d style, one needn''t worry about
the nohup
> > > problem, either.  Any insight?  (Or is this a 0.1.x problem?)
> > >
> > > Thanks,
> > > Philip
> > >
> > > On 3/12/07, Ezra Zygmuntowicz <ezmobius at gmail.com>
wrote:
> > > >
> > > >
> > > >         Yeah there are some weird interactions between
capistrano
> > > > and some
> > > > daemons, the old version of backgroundrb exibits this
behavior. That
> > > > way I get around it is by creating an init.d script, then
letting
> > > > capuse that to restart bdrb. Works like a charm. Here is an
init.d
> > > > script for Gentoo systems, it should be easy to adapt to any
other
> > > > unixy system.:
> > > >
> > > > #!/sbin/runscript
> > > > # Copyright 1999-2004 Gentoo Foundation
> > > > # Distributed under the terms of the GNU General Public
License v2
> > > > # $Header:
> > > > /var/cvsroot/gentoo-x86/www-servers/nginx/files/nginx-r1,v
> > > > 1.1 2006/07/04 16:58:38 voxus Exp $
> > > >
> > > >
> > > > depend() {
> > > >          need net
> > > >          use dns
> > > >          after gfs
> > > > }
> > > > start() {
> > > >          ebegin "Starting bdrb2"
> > > >            RAILS_ENV=demo
/data/toolbox/current/script/backgroundrb/
> > > >
> > > > start -d
> > > >          eend $? "Failed to start bdrb2"
> > > > }
> > > >
> > > > stop() {
> > > >          ebegin "Stopping bdrb2"
> > > >               kill -9 `cat /data/toolbox/current/log/
> > > > backgroundrb.pid` 2>/dev/null; true
> > > >          eend $? "Failed to stop bdrb2"
> > > > }
> > > >
> > > >
> > > >
> > > > Cheers-
> > > > -Ezra
> > > >
> > > >
> > > > On Mar 12, 2007, at 10:47 AM, Ben Reubenstein wrote:
> > > >
> > > > > Hello ~
> > > > >
> > > > > I am using the Capistrano recipe outlined in this post
to restart
> > > > > my backgroundrb server:
> > > > >
> > > > >
http://rubyforge.org/pipermail/backgroundrb-devel/2007-February/
> > > > > 000718.html
> > > > >
> > > > > My Version:
> > > > > ~~~~~~~~~~~~
> > > > > task :before_restart, :roles => :app do
> > > > >    restart_backgroundrb
> > > > > end
> > > > >
> > > > > task :start_backgroundrb, :roles => :app do
> > > > >    sudo "nohup
/var/www/rails/#{application}/current/script/
> > > > > backgroundrb/start "
> > > > > end
> > > > >
> > > > > task :stop_backgroundrb, :roles => :app do
> > > > >    sudo "kill -9 `cat
/var/www/rails/#{application}/current/log/
> > > > > backgroundrb.pid` 2>/dev/null; true"
> > > > > end
> > > > >
> > > > > task :restart_backgroundrb, :roles => :app do
> > > > >    stop_backgroundrb
> > > > >    start_backgroundrb
> > > > > end
> > > > > ~~~~~~~~~~~~
> > > > >
> > > > > The backgroundrb server is stopped and started but
hangs at the
> > > > > start_backgroundrb task.  Capistrano shows:
> > > > >
> > > > >   * executing task start_backgroundrb
> > > > >   * executing "sudo  nohup
/var/www/rails/*************/current/
> > > > > script/backgroundrb/start"
> > > > >     servers: ["host"]
> > > > >     [host] executing command
> > > > >  ** [out :: host] nohup: ignoring input and appending
output to
> > > > > `nohup.out''
> > > > >
> > > > > It will hang there and not restart the main web app
process.  I
> > > > > updated my gems to see if this was a version issue, but
am
> > > > > experiencing the same problem.  I also tried running
this
> > > > > task :after_restart, the web app is successfully
restarted, but it
> > > > > still hangs.
> > > > >
> > > > > Thanks in advance for any ideas on how to fix this.
> > > > >
> > > > > ~ Ben
> > > > >
> > > > > --
> > > > > Ben Reubenstein
> > > > > 303-947-0446
> > > > > http://www.benr75.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
> > >
> >
> >
> >
> > --
> > Ben Reubenstein
> > 303-947-0446
> > http://www.benr75.com
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20070316/80718471/attachment.html

Hi everyone,

I''ve a strange problem during those days, giving me a really bad  
headache

I''m using a worker that has someting like this:

for message in RunningMessage.find(:all,:condtions => ["......"])
	message.expired
end


The class RunningMessage use the "localization" plugin in this way;

def expired
	User.find("....").set_message(_("message_expired",Time.now))
end

The localization file has a key "message_expired" that looks like:

"message_expired","the message expires at %S"

When i run the method expired from inside rails, the user receives  
the translated message, but when the method is invocated by the  
worker the user receives just the not translated key in the message.

I''ve read something about the needs to re-initialize the plugins  
inside the workers, but at this time i''ve initilized the Localization  
plugin inside the Worker, in the User class, in the Message class,  
but nothing happens.

Some hints?

Thanks,
alessio.