Using Rails 3.0.1, Apache 2.2.9, and Passenger 3.0.0 on Debian.
For some mysterious reason, the Rails app is coming up in the development environment. I've double-checked the Apache configuration, the VirtualHost files, and so forth, and there are zero instances of "RailsEnv" or "RAILS_ENV" either in /etc/apache2 or in the app directory itself.
Worse, even if I do put a "RailsEnv production" line into the Directory block in the VirtualHost file, it makes absolutely no difference, and the app still comes up in the development environment.
Nothing interesting is logged if I set PassengerLogLevel to 1.
Any help either with what the problem is, or at least a course of action to identify the problem, would be greatly appreciated.
That's because with config.ru your app is detected as a Rack app, not a Rails app, and thus you need to set RackEnv instead of RailsEnv. A "Rails" app refers to a "Rails 1 or 2" app. Rails 3 apps are considered to be Rack apps.
After thrashing around for a while and trying random things off the 'net, I've found that deleting the config.ru file Rails generated solves the problem without otherwise causing the app to cease functioning. Why this was causing the problem remains unknown to me, but anybody coming across this having the same issue might try that solution.
Same symptom here, but none of the suggested solutions work for me. I first noticed this when I set my <body> tag to be <body class="<%= Rails.env %>"> and defining a background-color for the development class that is distinctly different from the background-color in the production class. All I ever see (production & development) is the development color. And of course viewing the source of the web page in the browser shows that the class being generated is development. I renamed config.ru to ~config.ru and restarted Apache2 and that didn't have an impact. I added RackEnv production to my *:80 virtual host file where the other Passenger attributes are set. That didn't have an impact. So I reset ~config.ru to be config.ru, restarted Apache2 and still don't see a change. I appreciate the explanation given by #Hongli of a Rack startup versus a Rails startup. I just wish my server would listen to him! I even did a recursive listing grepping for .htaccess -- none found. At least I think I know now where to keep poking around.
Apache 2.2.15, Rails 3.0.3, Passenger 3.0.2, Mac OS X Server 10.6.6
Related
I'm trying to add an environment variable to use in my Rails App. Currently, our app uses several environment variables defined in /etc/environment. They work fine. So I've added a new variable to /etc/environment (and rebooted for the hell of it). But when I try to access the new variable, its undefined. Printing out ENV.inspect shows all the original variables, but not my newly added one. Why oh why?
Running Apache 2 / Passenger 4 / Rails 4. Recently upgraded from Passenger 2 / Rails 3 if its significant.
Edit
Turns out the ones I thought 'work fine' don't work either (they're redefined in my Rails app). So none of the variables in /etc/environment are loaded into the app. Not sure why I thought that system worked, but it doesn't.
Might not be good news to you, but you have to reboot the instance to see it happen (or check the other tricks at that question).
You can also use SetEnv at your Apache config and just restarting apache itself will make your app see the new values.
ENV
Upgrading from Rails 3 - Rails 4 should not be a major concern for the ENV variables, unless the way Rails processes them will have changed.
We use the following:
This works for us with Rails 4, Ubuntu 12.04, Passenger, Apache 2
--
The problem you may have is that your Rails application has not updated since you added the new variables.
When you run a Rails app, it essentially loads an "instance" of the application, and then keeps loading it somehow. I'm not totally sure how it works, but I do know the likes of Passenger essentially "cache" a rails app whilst in production
This means if you're adding new Environment variables, perhaps the likes of Passenger has made it so the Rails application has not been updated? If this is the case you may wish to use the touch tmp/restart.txt command:
I wrote a demo HelloWorld Rails app and tested it with WEBrick (it doesn't even use a DB, it's just a controller which prints "hello world"). Then I tried to deploy it to a local Apache powered with Passenger. In fact this test is just to get Passenger working (it's my first deploy on Apache). Now I'm not even sure that Passenger works, but I don't get any error on the Apache side.
When I fire http://rails.test/ the browser shows the Rails 500 error page - so I assume that Passenger works. I want to investigate the logs, but it happens that production.log is empty! I don't think it's a permission problem, because if I delete the file, it is recreated when I reload the page. I tried to change the log level in conf/environments/production.rb, tried to manually write to log file with Rails console production and
Rails.logger.error('asdf')
it returns true but nothing gets written to production.log. The path (obtained per Rails.logger.inspect) is correct, and I remark that the file is recreated if I manually remove it. How can I know what's going on?
(I already checked the Apache logs, plus I set the highest debug level for Passenger but it seems a Rails problem, so is not logged by the server)
Assuming you're running Rails 3.2.1, this is a bug. It was patched in 3.2.2.
If you can't upgrade to 3.2.2 for any reason, this comment on GitHub has a workaround:
# config/initializers/patch_rails_production_logging.rb
Rails.logger.instance_variable_get(:#logger).instance_variable_get(:#log_dest).sync = true if Rails.logger
Setting this works on Rails 3.2.11:
Rails.logger = ActiveSupport::BufferedLogger.new(Rails.root.join("log","production.log"))
I'm learning Ruby on Rails. At the moment I'm just running my site locally with rails server in the OS X Terminal. What changes when a Rails site is run on a production box?
Is the site still started with rails server?
Any differences with how the db is setup?
Note: I'm running Rails 3.
A rails app can be run in production calling rails server -e production, although 99% of the time you'll be serving on something like passenger or thin instead of WEBrick, which means there's a different command to start the server. (thin start -e production for instance)
This is a complicated question, but the best place to start learning about the differences would be to look at the specific environment.rb files. When rails boots up it starts with the environment file that matches the called environment, ie if you start it in development it begins by loading your development.rb file, or if you're in production it will load the production.rb file. The differences in environments are mostly the result of these differences in the various environment config files.
Basically if a Rails 3.1 app is in production mode, then by default it is not going to be compiling assets on the fly, and a lot of caching will be going on that isn't happening in development. Also, when you get error messages they will be logged but not rendered to the user, instead the static error page from your public directory will be used.
To get more insight into this, I would suggest reading the relevant rails guides:
Rails Initialization Guide: http://guides.rubyonrails.org/initialization.html
Rails Configuration Guide: http://guides.rubyonrails.org/configuring.html
There are two contexts you can use the word "production" here. One of them is running the server in production mode. You can do this locally by,
RAILS_ENV=production ./script/server
The configuration for this is picked up from config/environments/production.rb. Try comparing this file with config/environments/development.rb. There are only subtle differences like caching classes. Development mode makes it easier so that it will respond to any changes you make instantly. Plus there are two different databases (by default) will be used namely yourproject_development and yourproject_production if you choose to run your server in either of these modes.
On the other hand, rails deployment to a production box is something different. You will need to pick your server carefully. You may have to deal with a deployment script may be capistrano. You may also need a load balancer such as netgear. The database also may require a deep consideration like size expectation, master/slave clustering etc.,
Note: I have never used Rails 3. This answer is biased towards 2.3.x.
I am trying to setup a Rails environment via CPanel. I've tried on several distinct hosting environments (on all of which I used CPanel to create the project) and I always get the following:
Is this something I've done wrong - I have to first create models/controllers etc - or something I need to bark up my hosting provider's tree about?
Have you tried running your app locally? If I remember correctly, for security reasons, the "about your application's environment" won't load unless it's from localhost.
If you are running your app in production mode (so it is recognized as it doesn't run locally), rails won't show this information, instead it will show this message.
I had this issue and wondering what's wrong when I first setup a new application in a server with passenger. The default environment of passenger is the production so it doesn't show this info. You have to set it up to development mode if you want to see them, to do that go to your virtual host file and add this:
RailsEnv development
When you start creating your application, delete the index.html from the public.
Maximum supported versions at this time are:
Ruby 1.8.7
RubyGems 1.8.25
Rails 2.3.18
Anything newer than that is a near guaranteed breakage and cPanel & WHM will be incapable of utilizing it in any way, shape, or form.
http://tickets.cpanel.net can assist you with removing your existing Ruby on Rails installations and reverting them back to cPanel supported and sanctioned versions (Ruby 1.8, RubyGems 1.8, and Rails 2). That is the only thing they can do for you at this time.
If you want to use any versions newer than this, then you will be unable to use the cPanel & WHM interfaces or management tools for it -- they simply will not work. You will then have to manually manage your RoR install by yourself through command line exclusively. None of it would fall under the scope of cPanel support.
I have a Rails app that is running on a production server with Apache and Phusion Passenger. The app works fine locally when using Mongrel, but whenever I try to load a URL on the production server, it returns HTTP 500. I know the server is working properly, because I can get the static elements of the application (e.g., JavaScript files, stylesheets, images) just fine. I've also checked the Passenger status and it is loading the app (it must be, since the app's 500 Internal Server Error page is returned, not just the default Apache one). Also, when I load the app via script/console production and do something like app.get("/"), 500 is also returned.
The problem is that there is nothing in the log files to indicate the problem. production.log is empty. The Apache error logs show no problems with Apache, either. I'm stumped as to what's going on and I'm not sure how to diagnose the problem.
I know I may have been a bit vague, but can anyone give a suggestion on what the problem may be? Or at least a way I can go about diagnosing it?
The answer for this specific situation was a problem with my app. One of the model classes used a different database connection than the rest of the app. This database connection was not configured properly. I think the reason why nothing was written to the log files is that Rails bailed out without having any idea what to do.
Since it may be helpful for others to see how I diagnosed this problem, here was my thought process:
The issue couldn't be with Apache: no errors were written into the Apache log files.
The issue probably wasn't with Passenger: Passenger wasn't writing any errors to the Apache log file, and it seemed to be loading my app properly, since passenger-status showed it as loaded and it was display my app's 500 Internal Server Error page (not the default Apache one).
From there I surmised that it must be something broken in my app that happened very early on in the initialization phase, but wasn't something that caused the app to completely bail and throw an exception. I poked around in the Phusion Passenger Google Group, and ultimately stumbled upon this helpful post, which suggested that the error may be a database connectivity issue. Sure enough, removing this misconfigured database and all references to it made the app work!
Have you tried running the app locally using Passenger?
Try running the application locally on Mongrel in Production mode, to make sure that there's no weird issues with that particular environment. If that works, then you know that it's not an issue with your codebase. Since your static components are being served properly, that tells me that Apache is working fine. The only gear in the system left is Passenger. At this point, I would say it's an improperly configured Passenger. You should post up your Passenger config file, and ask the question on ServerFault.
A couple of things to try :
Have you gone though the following from the docs:
6.3.7. My Rails application’s log file is not being written to
There are a couple things that you
should be aware of:
By default, Phusion Passenger runs Rails applications in production
mode, so please be sure to check
production.log instead of
development.log. See RailsEnv for
configuration.
*
By default, Phusion Passenger runs Rails applications as the owner
of environment.rb. So the log file can
only be written to if that user has
write permission to the log file.
Please chmod or chown your log file
accordingly.
See User switching (security) for details.
If you’re using a RedHat-derived Linux
distribution (such as Fedora or
CentOS) then it is possible that
SELinux is interfering. RedHat’s
SELinux policy only allows Apache to
read/write directories that have the
httpd_sys_content_t security context.
Please run the following command to
give your Rails application folder
that context:
Have you checked your vhost or httpf.conf file ? Do you have any logging directives ?
Check the top level apache log file
Try setting PassengerLogLevel to 1 or 2 or 3, as shown here http://www.modrails.com/documentation/Users%20guide.html#_passengerloglevel_lt_integer_gt
Do you have any rack apps installed ?
My suggestion would be to go right back to "Hello World" land and create the smallest possible Ruby example application and upload it to see if there is a problem with Passenger or Ruby on the server.
May be a silly suggestion but I suggest you start by increasing the logging levels on production while you are testing. Do this in config/environments/production.rb and use:
config.log_level = :debug
This should at least get you some sort of backtrace so you can start to find the problem.
If you still get nothing - you may find that you have an issue with something as simple as a missing gem/plugin on your production server. That sort of thing may well manifest as a "500" error and just not be very verbose for you.
Can you run the test suite on your production server?