On production server I have nginx+passenger and rails 3.1.2
Somehow it can't show we full output. I have the page with ~ 150 images and links underneath. But when page loads I can see only small part of them. Is it problem in nginx config? On my local all ok (MRI)
Nginx gzip helped me, I just turned on it in nginx.conf
Related
I have a rails app where users can manage large files (currently up to 15 GB). They have also the possibility to download the stored files.
Everything works perfect for files < 510 MB. But for > 510 MB, the download stops after 522,256 KB (510 MB).
I think thin produces this issue. When I start my dev server using thin, I cannot download the complete file. When I start the dev server using webrick, everything works.
I used top to compare the RAM/CPU behavior, but both server, thin and webrick, behave the same way. In development, both server read the complete file into RAM and then send it to the user/client.
I tried to change some options of send_file like stream, or buffer_size. I also set length manually. But again, I was not able to download the complete file using thin.
I can reproduce this behavior using Firefox, Chrome, and curl.
The problem is that my productive rails app uses 4 thin servers behind an nginx proxy. Currently, I cannot use unicorn, or passenger.
In development, I use thin 1.6.3, rails 4.1.8, ruby 2.1.2.
def download
file_path = '/tmp/big_file.tar.gz' # 5 GB
send_file(file_path, buffer_size: 4096, stream: true)
end
If you are using send_file, it is ideal to use a front end proxy to pass off the responsibility of serving the file. You said you are using nginx in production, so:
In your production.rb file, uncomment config.action_dispatch.x_sendfile_header = 'X-Accel-Redirect'.
You will also have to change your nginx configuration to accommodate Rack::Sendfile. Its documentation is located here. The changes amount to adding:
proxy_set_header X-Sendfile-Type X-Accel-Redirect;
proxy_set_header X-Accel-Mapping /=/files/; # or something similar that doesn't interfere with your routes
to your existing location block and adding an additional location block that handles the X-Accel-Mapping that you added. That new location block might look like:
location ~ /files(.*) {
internal;
alias $1;
}
You will know it is working correctly when you ssh to your production server and curl -I the thin server (not nginx) and see a X-Accel-Redirect header. curl (no -I) directly to the thin server should not send the file contents.
You can see my recent struggle with nginx and send_file here.
I am Using Rails 3.0.9 , Ruby 1.9.3p0
I am trying to upload a zip/tar file to server.
When i am uploading file 2.5mb. Evey thing works fine. But when i am uplaoing a zip file of 350mb. It creates error.(network error connection time out/ or "aborted" in response of firebug) .
In apache config, i had increased timeout from 300 from 300000 but nothing happened.
Is this possibly an apache setting? Or could it be something on their end? Any suggestions on where I should look would be greatly appreciated.
I have used both apache and Nginx. For such big file uploads i prefer NGINX. If you use Nginx you can set client_max_body_size to something like 500 MB inside your nginx.conf . One of the question who prefers the same here .
I have just performed a fresh install of Rails 3.2. The default "Welcome aboard" page was served fine when testing with built in webserver, however when I switched to Passenger together with Apache the Rails logo stopped showing up.
The image is located in /myapp/app/assets/images/rails.png and is called from document as assets/rails.png. This return 404.
I have set 755 permission on /myapp/app/assets folder and have Allow from all in my virtual host configuration.
Any help would be appreciated.
Check out in your config/production.rb that you have
config.serve_static_assets = true
and serving static assets is also enabled in your Apache and site configuration.
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?
I'm trying to get Redmine (a Ruby on Rails app) working. It works fine when started with ruby script/server webrick -e production, however, I'm having trouble getting it working in Apache with Passenger.
Accessing http://example.com/redmine returns the Redmine home page, but clicking any link (or even adding a / to the URL) results in a 404. According to the Rails log, a RoutingError occurs. For example, when opening the projects page: ActionController::RoutingError (No route matches "/projects.html" with {:method=>:get})
The Redmine directory is /var/www/localhost/htapps/redmine. I followed the documentation at http://www.modrails.org/documentation/Users%20guide.html#_deploying_a_ruby_on_rails_application (section 3.2), so there's a symlink at /var/www/localhost/htdocs/redmine pointing to ../htapps/redmine/public, and the Apache configuration contains DocumentRoot /var/www/localhost/htdocs and RailsBaseURI /redmine.
What is causing it to raise these RoutingErrors?
It looks like this issue was actually caused by the default .htaccess included with Redmine.
Redmine's .htaccess rewrites every request to end with .html. Redmine's routes expect .html-less requests.
Setting RewriteEngine to Off solved the issue for me.
http://ptspts.blogspot.com/2009/05/how-to-fix-railsbaseuri-sub-uri-with.html
The manual workaround (according to what is suggested on the pages above) is adding the line below to config/environments/production.rb:
config.action_controller.relative_url_root = '/redmine'
If not deploying to a Sub-URI and deploying using passenger, adding the rule RewriteRule ^(.*)$ dispatch.fcgi [QSA,L] to your public/.htaccess also solves the issue. As that rule is IfModule-ed out in the default .htaccess.
Another option is to delete .htaccess if you're not using it (As an example you may be using it for additional layer authentication with AuthType Digest etc). It is not required when deploying with passenger.
Even if you will manage to run Redmine in suburi, redmine still will have issues.
Some pages won't be parsed and displayed correctly, if displayed at all.
This issue is almost one year old and indicated for next minor release. Btw dozen minor releases came out, but it's not yet fixed. FCGI mode does not support sub-URI.