Cruisecontrolrb users - Aug 2007 - Problems getting CC.rb running as daemon

Hi,

I''m hitting a brick wall getting the CC.rb daemon mode working.  I
couldn''t find any discussions in the archives regarding this, but point
me
in the right place if I missed it.

I''ve got CC.rb working fine from ./cruise start.  However, when I try
to
run it as a daemon I get:

=> Booting Mongrel (use ''script/server webrick'' to force
WEBrick)
=> Rails application starting on http://0.0.0.0:3333
./script/../config/../vendor/rails/activesupport/lib/active_support/inflector.rb:250:
command not found: mongrel_rails start -p 3333 -a 0.0.0.0 -e production -P
script/../config/../tmp/pids/mongrel.pid -d

I have mongrel 1.0.1 installed.  Mongrel rails is sitting at
/usr/bin/mongrel_rails.  I can''t figure out why it isn''t found
by the
script.

I added a command like: puts "Path = #{ENV[''PATH'']}"
in the cruise loader
script, and it showed that /usr/bin is in the path.

No logs are generated.  Tried ./cruise start -d --trace  but didn''t get
anything more from that.

If anyone can suggest something I''d be grateful.

Thanks,
Theron

Hi,

On 8/29/07, ttrout at stormfish.net <ttrout at stormfish.net>
wrote:
> couldn''t find any discussions in the archives regarding this, but
point me
> in the right place if I missed it.
Hmm... As lame as it sounds, ''cruise start -d'' works for
[almost?]
everybody else. Certainly does for me :)
> If anyone can suggest something I''d be grateful.
If you look inside [cruise]/cruise, it simply removes the word
''start''
from the ARGV list and load script/server. So, the next question would
be: what happens if you run ''script/server -d'' instead of
''./cruise
start -d''? It should really be the same thing.

On another level of discussion, ''cruise start -d'' is a
half-hearted
option, anyway. Two reasons:

1. Mongrel isn''t very smart about PID files. If it goes down abruptly
(e.g., your build box suddenly loses power), it will refuse to come
back after reboot, saying ''hey, there is a PID file already
there''.

2. Dashboard starts the builders, but doesn''t care to keep them alive.
So, when a builder dies, it remains dead until somebody spots it and
hits the "build now" button.

So, a more robust setup would be to run the dashboard process as
''cruise start --without-builders'' from either runit or
/etc/inittab,
or Ubuntu''s upstart (/etc/event.d/), neither of which needs a service
process to fork out. And run each builder as a separate service:
''cruise build MyProject''. And perhaps have some health
checking daemon
(e.g., monit) supervising the whole thing.

--
Alexey Verkhovsky
CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com]
RubyWorks [http://rubyworks.thoughtworks.com]


-- 
Alexey Verkhovsky
CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com]
RubyWorks [http://rubyworks.thoughtworks.com]

Hi Alexey,

Thanks for the detailed reply.  You pointed out some good alternatives
which I wouldn''t have considered.  I may have to try your suggest #2 as
it sounds promising.  I should have mentioned that I''m running on an
AMD64 with Ubuntu.  Are there any known issues with CC.rb on 64 archs?

Alexey Verkhovsky wrote:
> Hi,
>
> On 8/29/07, ttrout at stormfish.net <ttrout at stormfish.net> wrote:
>   
> If you look inside [cruise]/cruise, it simply removes the word
''start''
> from the ARGV list and load script/server. So, the next question would
> be: what happens if you run ''script/server -d'' instead of
''./cruise
> start -d''? It should really be the same thing.
>   
I get the same result from the daemon and from ''scrip/server
-d''.  At
least it''s consistent.  Looking at the original message I thought it
was
odd that the inflector.rb class was identified as the error line.  In
one regard it makes sense, but it is possible that something isn''t
quite
right there.
> 1. Mongrel isn''t very smart about PID files. If it goes down
abruptly
> (e.g., your build box suddenly loses power), it will refuse to come
> back after reboot, saying ''hey, there is a PID file already
there''.
>   
I''ll check for any stragglers.
> 2. Dashboard starts the builders, but doesn''t care to keep them
alive.
> So, when a builder dies, it remains dead until somebody spots it and
> hits the "build now" button.
I''ll give both of your suggestions a try and post the results.

Thanks,
Theron

On 8/30/07, Theron Trout <ttrout at stormfish.net>
wrote:
> Are there any known issues with CC.rb on 64 archs?
None, it''s pure Ruby.
> I get the same result from the daemon and from ''scrip/server
-d''.
And what happens if you generate a skeleton Rails app and run that
with ''script/server -d''?

-- 
Alexey Verkhovsky
CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com]
RubyWorks [http://rubyworks.thoughtworks.com]

Hi Alexey,

I got it.  Ubuntu Feisty is still using Ruby 1.8.5 as the default
install.  Mongrel 1.0.2 will not work with Ruby 1.8.5.  See
http://www.urbanpuddle.com/articles/2007/08/17/mongrel-cluster-1-0-2-and-ruby-1-8-5


I manually installed Ruby 1.8.6 and then reinstalled Rails through ruby
gems.  Now everything is working just fine.

Thanks again for you help.

Best,
Theron Trout

Alexey Verkhovsky wrote:
> On 8/30/07, Theron Trout <ttrout at stormfish.net> wrote:
>   
>> Are there any known issues with CC.rb on 64 archs?
>>     
> None, it''s pure Ruby.
>
>   
>> I get the same result from the daemon and from ''scrip/server
-d''.
>>     
> And what happens if you generate a skeleton Rails app and run that
> with ''script/server -d''?
>
>

fyi, you''re going to have some issues w/ 1.8.6 if you''re using
test unit -
specifically, test::unit never returns an error code of 1 on failing tests,
so cruise will never fail for a unit test.  you can hack around it.
hopefully we''ll get a new version of ruby soon

On 9/5/07, Theron Trout <ttrout at stormfish.net>
wrote:
>
> Hi Alexey,
>
> I got it.  Ubuntu Feisty is still using Ruby 1.8.5 as the default
> install.  Mongrel 1.0.2 will not work with Ruby 1.8.5.  See
>
>
http://www.urbanpuddle.com/articles/2007/08/17/mongrel-cluster-1-0-2-and-ruby-1-8-5
>
>
> I manually installed Ruby 1.8.6 and then reinstalled Rails through ruby
> gems.  Now everything is working just fine.
>
> Thanks again for you help.
>
> Best,
> Theron Trout
>
> Alexey Verkhovsky wrote:
> > On 8/30/07, Theron Trout <ttrout at stormfish.net> wrote:
> >
> >> Are there any known issues with CC.rb on 64 archs?
> >>
> > None, it''s pure Ruby.
> >
> >
> >> I get the same result from the daemon and from
''scrip/server -d''.
> >>
> > And what happens if you generate a skeleton Rails app and run that
> > with ''script/server -d''?
> >
> >
> _______________________________________________
> Cruisecontrolrb-users mailing list
> Cruisecontrolrb-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/cruisecontrolrb-users/attachments/20070907/439607e9/attachment.html

Jeremy,

I wasn''t aware of that.  That''s a pretty startling bug.  Thank
you for
letting me know.

Best,
Theron

Jeremy Stell-Smith wrote:
> fyi, you''re going to have some issues w/ 1.8.6 if you''re
using test
> unit - specifically, test::unit never returns an error code of 1 on
> failing tests, so cruise will never fail for a unit test.  you can
> hack around it.  hopefully we''ll get a new version of ruby soon
>
> On 9/5/07, *Theron Trout* <ttrout at stormfish.net
> <mailto:ttrout at stormfish.net>> wrote:
>
>     Hi Alexey,
>
>     I got it.  Ubuntu Feisty is still using Ruby 1.8.5 as the default
>     install.  Mongrel 1.0.2 will not work with Ruby 1.8.5.  See
>    
http://www.urbanpuddle.com/articles/2007/08/17/mongrel-cluster-1-0-2-and-ruby-1-8-5
>
>
>     I manually installed Ruby 1.8.6 and then reinstalled Rails through
>     ruby
>     gems.  Now everything is working just fine.
>
>     Thanks again for you help.
>
>     Best,
>     Theron Trout
>
>     Alexey Verkhovsky wrote:
>     > On 8/30/07, Theron Trout <ttrout at stormfish.net
>     <mailto:ttrout at stormfish.net>> wrote:
>     >
>     >> Are there any known issues with CC.rb on 64 archs?
>     >>
>     > None, it''s pure Ruby.
>     >
>     >
>     >> I get the same result from the daemon and from
''scrip/server -d''.
>     >>
>     > And what happens if you generate a skeleton Rails app and run that
>     > with ''script/server -d''?
>     >
>     >
>     _______________________________________________
>     Cruisecontrolrb-users mailing list
>     Cruisecontrolrb-users at rubyforge.org
>     <mailto:Cruisecontrolrb-users at rubyforge.org>
>     http://rubyforge.org/mailman/listinfo/cruisecontrolrb-users
>
>