Trouble putting Rails App into Production with apache2

Rails
1

Hello,

I am trying to put a rails app I development into production. When I
alter my apache config like so:

SetEnv RAILS_ENV production
(used to be SetEnv RAILS_ENV development)

and reload apache, the site still stays in development mode. I do the
following on my homepage to check what environment I’m using:
<%= RAILS_ENV %>

However, if I add this line to my environment.rb:
ENV[‘RAILS_ENV’] ||= ‘production’

The application successfully switches into production mode.

I do have complete control over my server, so I’m trying to “properly”
put the application in production mode, vs. editing the environment.rb
file.

Any suggestions? Let me know if posting more code / commands would be
helpful.

Thanks,

Sean

2

What does

SetEnv ENV[‘RAILS_ENV’] production

get you? I noticed this weekend that Apache2 seems to define ENV in some
kind of weird way. If it at all does. ENV == {} in environment.rb for
me.
I’m curious what the deal is.

RSL

3

Hi Russell,

I tried as you suggested, but it doesn’t work. I found this though:

http://lists.radiantcms.org/pipermail/radiant/2006-October/002105.html

which states

“SetEnv happens on a per-request basis, but your Rails process starts
in the
context of Apache not that of a request.”

and that statement leads me to believe that it doesn’t matter what I
have configured in my site-specific configuration.

Where’s the right spot to configure for a Rails/Apache2/fcgi setup to
switch from development to production?

thanks,

Sean

4

If you are using Apache2 to proxy to Mongrel, then the Mongrel
processes need to be running in Rails production mode, and nothing you
do in Apache config will help.

mongrel_rails -e production -p …

5

Anyone? This is puzzling me too.

RSL

6

What if we’re not using Mongrel?

RSL

7

On Mar 29, 2007, at 9:41 AM, Russell N. wrote:

What if we’re not using Mongrel?

Perhaps you should be? :slight_smile:

Try setting the environement variable:

RAILS_ENV=production

Before starting up your Rails instance and that should do the trick.

–
– Tom M., CTO
– Engine Y., Ruby on Rails Hosting
– Reliability, Ease of Use, Scalability
– (866) 518-YARD (9273)

8

Oh, I’m sure I should be but my budget has me on shared hosting at the
moment and last time I looked Mongrel and shared hosting didn’t want to
play
well together. I do run Mongrel on my desktop to develop but even here
when
I use Apache[2] I don’t mongrelize because that’s not what the end host
is.
:confused:

RSL

9

Are you on Dreamhost? I’ve had to add this to the top of my
dispatch.fcgi files for Rails apps on Dreamhost:

ENV[‘RAILS_ENV’] = ‘production’

I also have a cron that hits the site every 5 minutes to keep it in
memory.

10

Hi Folks,

I decided just to live with putting the application into production by
modifying the environment.rb file.

I appreciate all your suggestions. Thanks a lot.

Sean

11

Yeah. I am a DHer. There’s also the stopgap line like that you can
uncomment
in config/environment.rb [which for me was just as easy to uncomment via
Capistrano on deploy] but I was curious about finding the real solution
to
Apache2’s problem. Which, I guess, we did find with that whole request
scope issue. :confused:

I did discover the perfect reaper action though, for Apache2
[presuming
you’re not using Mongrel]

script/process/reaper -a graceful -d dispatcher.fcgi

Seems like the default reaper task doesn’t actually restart the
dispatcher.
If you run it multiple times, watch the PID[s] it says it’s restarting.
They
never change because they’re never affected. Graceful works nicely
though
and actually stops the dispatcher. Just a tip. :slight_smile:

RSL