cron job errors

[Brandon Casci]

Hello

I've got a fresh rubber install with an unusual problem. Any tasks using  script/runner kick out this error

Rails requires RubyGems >= 1.3.2. Please install RubyGems and try again

The tasks work from the command line though.

The path variables are correct, gems is installed an up to date. I did a system update of gems as a precaution, but it said there was nothing to update, which is expected.

What do you think I should look at next?



--
=========================================
I'm having a bout of spondylosis, so I can't hammer away at the keyboard too long. Please don't mistake short e-mails for rude e-mails..
=========================================

[Brandon Casci]

I destroyed and recreated the instance just to have a fresh start. Same problem. Using the latest version of rubber, for me anyway, it looks no script/runner jobs kicked off with cron work because Rails can't find RubyGems.

I added 'export RUBYOPT=rubygems' to root's .profile thinking it may help, but no luck.

I'm sure others have upgraded rubber, and use script/runner from cron, so maybere there is something in my rails app that is causing confusion?

[Matthew Conway]

Can you run runner from the command line? 

try something like:

cd $RAILS_ROOT; ./script/runner 'puts "hi"'

I usually only see that error when I'm missing gem that is present in environment.rb as a config.gem

Matt

--

You received this message because you are subscribed to the Google Groups "rubber" group.
To post to this group, send email to rubbe...@googlegroups.com.
To unsubscribe from this group, send email to rubber-ec2+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rubber-ec2?hl=.

[Brandon Casci]

Everything works great from the command line. I though there might be a missing gem too, but I don't see there is one missing. IF there was a config.gem missing the app wouldn't start either.

[Matthew Conway]

Try putting a job in cron that saves env to a file, e.g.

* * * * * /usr/bin/env > /tmp/env.log 2>&1

Are you using enterprise ruby?  The rubber setup for that is a little hokey in that the standard ruby gets installed as well, so make sure PATH is pointing to he right one.  I had made some changes to fix this lately, and it works for me, but I may have missed something.  Ideally I should be using a debian package which replaces standard ruby, but the only binary one from brightbox is a little out of date.

* * * * * ruby --version > /tmp/rubyver.log 2>&1

* * * * * which ruby > /tmp/whichruby.log 2>&1

Matt

[Brandon Casci]

Ah...that's got to be the change then. I'm using enterprise ruby with the latest deployment.

ruby 1.8.7 (2009-06-12 patchlevel 174) [i686-linux], MBARI 0x8770, Ruby Enterprise Edition 2009.10

'which ruby', from both cron and command line produce the same path:

/usr/local/bin/ruby

[Brandon Casci]

Forgot to include this.....the env output. Everything seems to be ok.

SHELL=/bin/sh
MAILTO=brando...@gmail.com
PATH=/usr/local/bin:/usr/local/sbin:/usr/local/mysql/bin:/usr/bin:/bin:/sbin:/usr/sbin
RUBBER_ENV=production
PWD=/root
SHLVL=1
HOME=/root
RAILS_ENV=production
LOGNAME=root
_=/usr/bin/env

[Matthew Conway]

Looks like you are using the right ruby, assuming it is enterprise ruby that you want.  Maybe gems got installed for system ruby instead?  You can also try adding RUBYOPT=rubygems to the common/crontab

[Brandon Casci]

I tried that too. No dice. Pretty strange eh?

[Brandon Casci]

ahhh...new error kicked out form cron

/usr/bin/ruby: no such file to load -- ubygems (LoadError)

I can assure you though, my RUBYOPT=rubygems, not ubygems

[Brandon Casci]

i think I figured it out....

[Matthew Conway]

I've seen that when running system ruby (/usr/bin/ruby) instead of enterprise ruby (/usr/local/bin/ruby).  RUBYOPT is causing rubygems to try and be loaded, but its not available to the system ruby as it was installed for the enterpise ruby.

Let me know if I need to fix anything in rubber once you figure it out.

Matt

[Brandon Casci]

Ok....the problem was the crontab file was a little older, so the jobs had a full path to the old ruby in them (/usr/bin/ruby). Thoguh like you said, that version of ruby is still installed, so off it went. So the jobs were not executing with enterprise ruby. Thanks...I probably would have missed this detail for longer without your help.

[Matthew Conway]

Ok, cool.  The switching between ruby/entruby is a little hokey, I need to come up with something better :/

Matt