rack-zippy and option -d in production env doesn't serve static assets

Question

I've a really weird problem here. I'm using the rack-zippy gem in my rails application and if I start it in development environment without pre-compiled assets it works like a charm. With the -d param and without.

In production mode (same machine, same project, same directory, same gems) it works too. But if I start it with the -d param (bundle exec rails server -d) to daemonize the server, the pre-compiled assets will not be served. Can reproduce that with thin and webrick but NOT with unicorn.

The log says:

ActionController::RoutingError (No route matches [GET]
    "/assets/application-b9b75968aed42128cfd75fb78df1e4d1.js"):

but:

$ l public/assets/application-b9b75968aed42128cfd75fb78df1e4d1.js
-rw-r--r-- 1 public/assets/application-b9b75968aed42128cfd75fb78df1e4d1.js

From config/environments/production.rb:

config.serve_static_assets = true

From config/application.rb:

config.middleware.swap(ActionDispatch::Static, Rack::Zippy::AssetServer)

And:

$ rake middleware            
use Rack::Sendfile
use Rack::Zippy::AssetServer
(...)

I'm somewhat confused right now. Any ideas?

Elm

Answer 1

Ouch, I've never encountered this, but I'll tell you my gut feel and maybe you can get somewhere with this. (Thanks for reporting it on the Github issue tracker).

So unicorn is OK, but thin and webrick are not, mmmm.

My guess is that the working directory used by the daemon process for thin and webrick is not Rails.root. You might want to try debugging this line in rack-zippy to see what the path is being searched for the asset file: https://github.com/eliotsykes/rack-zippy/blob/master/lib/rack-zippy.rb#L87

rack-zippy since version 1.1.0 (which you're probably using if you're using the latest Gem) passes all requests it can't find a file for on to the remaining middleware stack.

In development+daemon mode, rack-zippy will be passing the request onto the asset pipeline, so I think we can assume that the asset pipeline has no problems with daemon mode.

In production+daemon mode, the asset pipeline is probably disabled (as you'd want), and rack-zippy will be passing the request onward if it can't find the asset file (which is probably the case if the working directory is not Rails.root), and then the remaining middleware will give you the routing error you see.

If you enabled the asset pipeline in production (very much not recommended), then I would expect the routing error would disappear, and rack-zippy would not be doing anything useful.

Sorry I don't have anything more solid for you to go on.

Altercate

Thanks for the advice Eliot. Nice to hear a statement from the gem developer itself. I'll try to follow your thoughts and debug it those days and give you feedback :) – Elm

Thanks, I'm looking forward to finding out how you get on, good luck! – Altercate

Ok, I've tried to debug that. First thing I've found: The pathes in the serve? method are the same. That's not the problem. But the method returns false if the server runs in daemon mode. If dropped a simple Dir.pwd logging into the serve? method which revealed the cause of all evil (and approves your gut feeling): Dir.pwd without -d is the rails root dir. Dir.pwd with -d is just '/'. – Elm

Answer 2

Until a fix is released in the next version of rack-zippy, to workaround this issue, where you have this line (probably in config/application.rb or config/initializers/rack_zippy.rb):

Rails.application.config.middleware.swap(ActionDispatch::Static, Rack::Zippy::AssetServer)

Replace it with:

# Rails.public_path as last argument here gets passed into the Rack::Zippy::AssetServer
# constructor to override the default asset_root argument value.
Rails.application.config.middleware.swap(ActionDispatch::Static, Rack::Zippy::AssetServer, Rails.public_path)

Altercate