So, there is some serious confusion about this in the code. I now know
of two other folks (one you, Jason) who struggled with this besides me.
I solved it by having a shared/config/backgroundrb.yml on the server,
which we link into config of the app on deploy (capistrano). It looks
like this:
:backgroundrb:
:port: 11006
:ip: 0.0.0.0
:environment: staging
:lazy_load: true
:debug_log: true
:schedules:
:notification:
:deliver_event_reminders:
:trigger_args: 0 */3 * * * * *
As you can see, we have the environment in the config. The code in
meta_worker obviously disrespects -e. Now, you ALSO need to pass -e
staging, so that when Rails boots, it has the correct environment.
Here is our init.d line:
/var/www/apps/railsapplication/current/script/backgroundrb "$1" -e
staging >> /var/log/backgroundrb
I may patch this at some point, but it's already eaten a bit too much
time (not you, but solving it originally).
aiwilliams
On Apr 30, 2008, at 12:49 PM, Jason Lee wrote:
So I tried this and my debug still says the env is development..
Guess I'll have to start hacking to see why this is..
- jason
On Wed, Apr 30, 2008 at 8:15 AM, Stevie Clifton <[EMAIL PROTECTED]
> wrote:
Hey Jason,
To get the environment passed in correctly, I use:
RAILS_ENV=staging ./script/backgroundrb start
And just to make sure, you're aren't actually calling your staging
environment "stage" are you? Or if you are, you have an environment
intentionally named that, right? Just had to ask :).
stevie
_______________________________________________
Backgroundrb-devel mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/backgroundrb-devel
_______________________________________________
Backgroundrb-devel mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/backgroundrb-devel
