I have an issue when trying to deploy my rails app in production mode on my server using phusion passenger with nginx.
My app runs perfectly fine in development mode, with this configuration file :
server {
listen 80;
server_name domain.co;
root /home/me/projects/myapp/public;
passenger_enabled on;
rack_env development;
}
What I did is simply switch the development with production.
When I do this, I simply get a "502 Bad Gateway" message.
A production.log file is created, but it is 0 bytes.
I could not find any other log that indicate whether there is an issue or not (nothing else in the log folder, nothing in /etc/var/nginx/. . .).
When I try to run passenger-status in my project structure, passenger tells me it is not running here. I get a proper status message when I do the same thing in development mode.
My guess is that passenger tries to start the app but something fails early in the process; the issue is that I can't get to know why because I am unable to find any log.
I have found several other questions on Stack Overflow about the same problem, but most of them get some kind of log. I guess if I could get access to the error message somehow that would help.
Is there anything obvious I miss?
Thanks,
Julien
And as usual, Stack Overflow is great for rubber duck debugging and now I feel extremely stupid.
The issue seems to come from the fact that I put my SECRET_KEY_BASE environment variable in the .bashrc file; which doesn't work on my production environment.
If I put the export statement in **~/.rvm/environment/ruby***** instead, everything works fine. . .
Related
This is my first time deploying a Rails app to a production server, I have already done almost everything. I'm stuck with the process to make the app run in production mode, I already typed
$ export RAILS_ENV=production
and
$ echo $RAILS_ENV
and the terminal throws that I am in the production mode, but when I go to a url in my app not yet defined by me, the server is still debugging the templates, I just want the server throws the default 404 page.
Be patient to me I'm new in this. :)
You need to change the rails_env setting in nginx/conf/nginx.conf, as follows:
server {
listen <port_number>;
passenger_enabled on;
root /home/<username>/webapps/<app_name>/<app>/public;
server_name localhost;
rails_env production;
}
If you do this and are greeted with a "502 Bad Gateway" error for your efforts, the issue may be that you don't have the SECRET_KEY_BASE environment variable set. You can generate a suitable value with rake secret, and then add export SECRET_KEY_BASE="<secret>" wherever you're setting other environment variables.
Webfaction's Rails deployment documentation has improved substantially, but this is one of a number of non-intuitive steps it still skips over.
I think I've read every question and answer on SO related to passenger/nginx and 403 errors, but none have lead me to a solution, so here I go...
I had Nginx (1.0.6) with Passenger (3.0.9) running beautifully for a rails app for many, many months with no real issues. Tonight I decided to upgrade from Passenger v3.0.9 to v3.0.12 to take advantage of a new feature. After running the install according to the provided instructions (using RVM), I went to the URL served by my rails app and got the dreaded 403 error. The nginx log file first had me thinking it was a permissions error:
directory index of "/home/SimfoUsers/public/" is forbidden, client: , server: , request: "GET / HTTP/1.1", host: ""
But after checking every possible permission, I no longer think that is the issue. I think the problem is actually that passenger is somehow not actually running, and the page is being served as a "normal" webpage by nginx. This is supported by the fact that if I add an index.html file to my rails public directory (/home/SimfoUsers/public/), nginx serves up this file as one would expect. Also, if I run passenger-memory-stats, ZERO passenger processes are running. Shouldn't nginx automatically spawn passenger processes whenever needed, or am I completely missing something here?
Here are the relevant parts of my nginx.conf file:
http {
passenger_root /usr/local/rvm/gems/ruby-1.9.2-p290#Simfo/gems/passenger-3.0.12;
passenger_ruby /usr/local/rvm/wrappers/ruby-1.9.2-p290#Simfo/ruby;
...
server {
listen 80;
server_name simfo.info www.simfo.info;
root /home/SimfoUsers/public;
passenger_enabled on;
}
}
Basically the only thing that I changed from my previously working config file is to update the passenger_root and passenger_ruby directives to reflect the new version of passenger (3.0.12). So if this is a config file issue, I'm really at a loss to understand it...
I'm not sure whether to just delete this question, or leave it in case it can save someone else the same frustration. This definitely is a face palm moment...
In desperation, I finally rebooted the server. After that, everything worked fine. It seems that at some point the passenger-related processes died and were not re-spawned automatically. One would think that after a fresh installation and reboot of nginx, passenger would be restarted, but apparentally this is not the case. My only advice to anyone having a similar problem is to issue a ps aux | grep passenger (or tasklist on Windows?). You should see one or two processes related to passenger. If not, then something strange is going on, and a reboot might help you as well.
I'm having a real tough time diagnosing a 500 error from my application running in production. I've had it working before, but after re-deploying via Capastrano I am unable to get it going.
Here are the facts:
The server is setup with nginx + passenger, and I'm using
PostgreSQL.
Static assets are working properly, as in I'm able to access them just fine in a browser.
I can access the rails console via RAILS_ENV=production bundle exec rails console and perform Active Record actions (like
retrieving data from the db).
Within console, I can run app.get("/"), which returns a 500 error as well (after first showing the query that was run to load
the model).
The production.log file is never written to. I've set permissions 777 on it just for the hell of it. I've also set the log level to
:debug with nothing to show for it.
The nginx log (which passenger also uses) shows no indication of errors, it just notifies about cache misses.
Because nothing of use is being logged, I have no idea what to do here. I've tried setting full permission on the entire app directory with no help. Restarted the server multiple times, nothing. The database is there and rails can clearly communicate with it. I'm not sure what I did to get it to run the first time around. I just don't know why rails isn't outputting anything to the log.
Okay, I figured this out. The app ran fine in development mode, so I knew something production-specific was screwing it up. I went into config/environments/production.rb and changes these settings:
# Full error reports are disabled and caching is turned on
config.consider_all_requests_local = false # changed from true
config.action_controller.perform_caching = true # changed from false
And then after restarting passenger, rails showed me the error w/ stacktrace. Turns out I was forgetting to precompile the asset pipeline!
Things to check
1) Are you sure you are running in production environment?
Check to see if any entries are in the development.log file
2) Set up your app to email you when a 500 error occurs with a full stack trace. I use the Exception Notifier gem but there are plenty of other solutions for this.
3) When checking your app in the console are you sure you are starting the console in production mode? It is possible that the app is not starting up at all and you just forgot to set the production param thereby thinking that the app runs fine when it doesn't.
4) Are you getting an nginx 500 error or the Rails 500 error? If nginx then it is likely that your app is not starting at all and highly unlikely that you will get any rails error in your log file. The assets are static files and navigating to them proves nothing other than that they exist.
5) Are you sure you are checking the right folder on the server? Sounds really stupid but capistrano could be deploying the app to a folder that is different to the folder that nginx is looking for for your app so double check both the folder capistrano is deploying to and the folder that nginx is looking for are the same.
Just a suggestion, I would use puma rather than passenger. It's awesome with nginx.
My problem is passenger's log file (error.log) has nothing. Then it's a rotation log issue. Run
passenger-config reopen-logs
solved my problem. More.
Have you tried running in development mode to see if the error reports itself?
I am using rails(2.3.10)/passenger(2.2.15)/nginx(0.7.67) , when i run my application, it give me "502 Bad Gateway" and without any production log, my conf file is :
1 server {
2 listen 80;
3 server_name www.why.bz;
4 root /usr/local/apps/why/pro/public;
5 access_log /usr/local/apps/why/pro/log/access.log;
6 passenger_enabled on;
7 }
who can give me some tips, thanks!
I've done Rails deployments full-time for the last couple of years, so hopefully I can help. You've probably figured this problem out by now, but here are some questions to think about for next time:
Since this is a Ruby on Rails application, can you tell where the error is coming from: Nginx or Rails itself? That sounds more like a Nginx issue, but it would be good to know. A quicky peek into the Rails production.log or Nginx's error_log should elucidate this info.
How are you connecting to the application: web browser or command line? Is the IP and hostname set correctly (try the Linux "dig" command to verify)? Are you trying to hit http://localhost:80 ?
There are error log commands that nginx takes that could be configured to help you debug the issue (much like the access_log line): http://wiki.nginx.org/CoreModule#error_log
Lastly, verify the permissions that are set on your web files: The nginx web server needs to be able to access them. At least "read" permissions are needed.
Good luck,
Harmon
change it to
listen 443;
it could be as simple as that.
It could be that your secret key base is missing for the required stage.
One thing that I sometimes forget, especially if I don't start with a staging environment and then add it later, is to add the following to my secrets.yml file:
staging:
secret_key_base: <%= ENV["SECRET_KEY_BASE"] %>
This is telling Rails to get the secret_key_base value from the environment variable, SECRET_KEY_BASE. You must specify this variable by placing this in your nginx configuration:
passenger_env_var SECRET_KEY_BASE yoursupersecretkeybase;
If you don't have a SECRET_KEY_BASE, you can generate one with:
bundle exec rake secret
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?