My question is similar to this one Rails 3.2 Asset Pipeline with Passenger Endless Errors except that when I try to actually go to
<link href="/assets/application-eed7996ee9017637f923133371ab3e92.css" media="all" rel="stylesheet" type="text/css" />
I get a 404. Here's the thing I don't understand. It is looking in /assets/, but when I look at the code that was deployed, the assets are only in /public/assets, which is actually a symlink to /var/www/myapp/shared/assets. So what in the world is responsible for telling the app that looking in /assets will produce correct results??
I am using Rails 3.2.0, ruby-1.9.3-p125, deploying to Ubuntu, Apache, and Thin.
I should clarify: My assets are indeed deployed to the server. Everything works perfectly fine until they need to be served, in which case production.log tells me it's looking for them in /assets/application-eed7996ee9017637f923133371ab3e92.css, which 404's.
For every request my thin.log says
cache: [GET /] miss
and production.log says
ActionController::RoutingError (No route matches [GET] "/assets/application-abecf2e096af9ee80697fd49e79a55e7.js"):
UPDATE
@Brandan thanks for the help. My assets are indeed in RAILS_ROOT/public/assets
. I put this in my Apache vhost file:
DocumentRoot /var/rails/myappname/current/public
RewriteEngine On
XSendFile On
XSendFilePath /var/rails/myappname #not even sure if this line is needed
<LocationMatch "^/assets/.*$">
Header unset ETag
FileETag None
ExpiresActive On
ExpiresDefault "access plus 1 year"
</LocationMatch>
My RAILS_ROOT/config/environments/production.rb settings:
config.cache_classes = true
config.consider_all_requests_local = false
config.action_controller.perform_caching = true
config.serve_static_assets = false
config.assets.compress = true
config.assets.compile = false
config.assets.digest = true
config.action_dispatch.x_sendfile_header = "X-Sendfile" # for apache
I've been having this problem for days now. Thought it was an issue with capistrano or the ruby version however I'm pretty sure it's permissions related too.
My configuration was pretty much the same as yours although I'm also using Unicorn.
Here's what I did to sort:
Temporarily remove the following section because I think that was causing problems with the troubleshooting:
<LocationMatch "^/assets/.*$">
Header unset ETag
FileETag None
ExpiresActive On
ExpiresDefault "access plus 1 year"
</LocationMatch>
Perhaps get it all working and then add it back in. I don't think it's the cause of the problems however, when diagnosing things like this, it's best to remove as much as you can to find the culprit.
Run a chown -R xxx.xxx (replace xxx with your application user or web user) on the public directory. As soon as I did so, the css appeared again.
(What I did but maybe not essential) You might also want to install locally without cap. just in case there's an issue with it. That also worked for me.
Completely wipeout tmp/cache and public/* just in case.
Restart your apache server a couple of times.
You can see a gist of my conf. here
Delete the following lines from your Apache configuration.
ProxyPass / balancer://thinservers/
ProxyPassReverse / balancer://thinservers/
The answer came from In Rails, should I enable serve_static_assets?.
Typically, your assets should only exist in /public/assets
for a deployed application.
Apache should be configured so that its DocumentRoot
is your RAILS_ROOT/public
. Then it will serve http://example.com/assets/whatever.css
from RAILS_ROOT/public/assets/whatever.css
, and it never goes through Rails for static assets.
Have you restarted your application since you precompiled your assets? Sometimes Rails is expecting an older/newer compiled version of your assets than is currently deployed.
Try removing the ProxyPass
and ProxyPassReverse
directives from your apache/thin configuration. The P flag in your rewrite rule is already performing the proxy pass that you desire.
See http://httpd.apache.org/docs/2.0/mod/mod_proxy.html for more information.
Passanger knows its a RoR application as there is a config.ru file.
The same error you are reporting happened to me due to wrong permissions. Apache was not able to serve the files inside assets
, but was able to send the files on public/
In my case I use capistrano so assets
was a symlink to shared/public/assets
.
what I did was:
chmod -R o+x shared/
x permissions are required to list and access directories. After that it worked. You have to make sure that assets
has +x for others