cache: [GET /] miss

[Revence Kalibwani]

Hello, Phusion Passengers;

I honestly think that Phusion Passenger is the best thing to happen to
web development since Rails (which itself was the best thing since CGI
1.1 was implemented). In the past, there was a good excuse to not be
doing Rails apps. With Passenger, I honestly do not know what excuse
one can give, with a straight face, for not using Rails. Thank you,
Phusion and dev team, for making the right thing to do the easy thing
to do.

There is something about Passenger, though, that I have completely
failed to understand.
On FreeBSD, Passenger doesn't serve requests that are not in public.
Files in public serve perfectly, but not those that go through a
controller.

My version info:
FreeBSD 8.2-RELEASE
Rails 3.1.0
Ruby 1.8.7
Apache 2.2

This is what the relevant part of the Apache conf looks like:

LoadModule passenger_module /usr/local/lib/ruby/gems/1.8/gems/
passenger-3.0.9/ext/apache2/mod_passenger.so

...

<IfModule passenger_module>
PassengerRoot /usr/local/lib/ruby/gems/1.8/gems/passenger-3.0.9
PassengerRuby /usr/local/bin/ruby18
</IfModule>

...

<VirtualHost *:80>
ServerName new.1st.ug
DocumentRoot "/home/revence/hacks/new.1st.ug/scyfy/public"
<Directory "/home/revence/hacks/new.1st.ug/scyfy/public">
Allow from all
AllowOverride all
Options -MultiViews
</Directory>
</VirtualHost>

Apache starts up fine, and loads the module fine. This is what the
error log looks like, straight after a restart:

[Mon Sep 19 11:36:22 2011] [notice] Apache/2.2.11 (FreeBSD) DAV/2 PHP/
5.2.9 with Suhosin-Patch Phusion_Passenger/3.0.9 mod_wsgi/2.8 Python/
2.7.2 mod_ruby/1.3.0 Ruby/1.8.7(2011-06-30) mod_ssl/2.2.11 OpenSSL/
0.9.8q configured -- resuming normal operations

And this is what the error log looks like, when a request has been
made:

[Mon Sep 19 11:36:22 2011] [notice] Apache/2.2.11 (FreeBSD) DAV/2 PHP/
5.2.9 with Suhosin-Patch Phusion_Passenger/3.0.9 mod_wsgi/2.8 Python/
2.7.2 mod_ruby/1.3.0 Ruby/1.8.7(2011-06-30) mod_ssl/2.2.11 OpenSSL/
0.9.8q configured -- resuming normal operations
cache: [GET /] miss

That last line is what happens when I make a request. It only happens
for requests going through the controller. This is the access log's
testimony:

196.0.26.50 - - [19/Sep/2011:11:37:05 +0300] "GET / HTTP/1.1" 500 728
"-" "Opera/9.80 (X11; Linux i686; U; en-GB) Presto/2.9.168 Version/
11.51"
196.0.26.50 - - [19/Sep/2011:11:37:09 +0300] "GET /favicon.ico HTTP/
1.1" 200 - "http://new.1st.ug/" "Opera/9.80 (X11; Linux i686; U; en-
GB) Presto/2.9.168 Version/11.51"

It happens on controllers whether they have caching directives or not.
What is the process that gets me to that (undesired) behaviour, and
what could I do to change it?

[Hongli Lai]

Thanks. :)

As for your problem, this can happen if Phusion Passenger doesn't
detect your application. Phusion Passenger checks for the file
$DOCUMENT_ROOT/../config.ru or
$DOCUMENT_ROOT/../config/environment.rb, and if one of those files are
present then Phusion Passenger will start the Rack/Rails app and
forward the request, but only if no corresponding .html file exists
for the URL. Failure to detect the application can happen if Apache
doesn't have the appropriate permissions to check for the existence of
those files.

> --
> You received this message because you are subscribed to the Google Groups "Phusion Passenger Discussions" group.
> To post to this group, send email to phusion-...@googlegroups.com.
> To unsubscribe from this group, send email to phusion-passen...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/phusion-passenger?hl=en.
>
>

--
Phusion | Ruby & Rails deployment, scaling and tuning solutions

Web: http://www.phusion.nl/
E-mail: in...@phusion.nl
Chamber of commerce no: 08173483 (The Netherlands)

[Revence Kalibwani]

2011/9/19 Hongli Lai <hon...@phusion.nl>

Thanks. :)

My pleasure. :o)

 

As for your problem, this can happen if Phusion Passenger doesn't
detect your application.

I think Phusion detected the application, since it serves the public directory.

 

Phusion Passenger checks for the file
$DOCUMENT_ROOT/../config.ru or
$DOCUMENT_ROOT/../config/environment.rb, and if one of those files are
present then Phusion Passenger will start the Rack/Rails app and
forward the request, but only if no corresponding .html file exists
for the URL. Failure to detect the application can happen if Apache
doesn't have the appropriate permissions to check for the existence of
those files.

Apache has the necessary permissions, not least because the conf says so (it relaxes the rules, as the docs recommend), and when I su to the user www, I can cat any of the files in $DOCUMENT_ROOT.

In other words:

$ pwd

/home/revence/hacks/new.1st.ug/scyfy

$ ls

Gemfile app doc script

Gemfile.lock config lib test

README config.ru log tmp

Rakefile db public vendor

$ whoami

www

$ find . -exec cat {} \; > /dev/null

$ echo $?

0

It seems to me that Passenger has a default of some sort (at least in this case) to fail when no static is found, without ever checking with the controller. Even a certain exception I put at the top of the action place is never hit.

--
Revence

[Hongli Lai]

Phusion Passenger passes the request to Apache if it doesn't detect the request as a dynamic request that the app should handle.

Try setting RackBaseURI / to force detection as Rack app.

Sent from my Android phone.

Op 19 sep. 2011 13:38 schreef "Revence Kalibwani" <rev...@1st.ug> het volgende:

[Brian Weaver]

Do you have rack-cache installed? I spent a good day+ tracing through Passenger/Rails/Rack and lots of other gems to find out why lines similar to that one was appearing.

Add the following to your production.rb or development.rb file to get rid of the 'cache: ....' line

config.action_dispatch.rack_cache = {:metastore => "rails:/", :entitystore => "rails:/", :verbose => false}

I pulled that line from within the "middleware" configuration of Rails an just changed the 'verbose' from true to false.

-- Brian

On Sep 19, 2011, at 4:51 , Revence Kalibwani wrote:

> Hello, Phusion Passengers;

[Revence Kalibwani]

I have set RackBaseURI / in global settings exclusively, in domain-level settings exclusively, and in both scopes at once, and the problem persists.

I am going now to try Mr. Weaver's suggestion and give feedback.

 

--
Revence

[Revence Kalibwani]

----- Original Message -----
From: "Brian Weaver" <cmdrcl...@gmail.com>
To: <phusion-...@googlegroups.com>
Sent: Monday, September 19, 2011 2:56 PM
Subject: Re: [phusion-passenger] cache: [GET /] miss

> Do you have rack-cache installed? I spent a good day+ tracing through
> Passenger/Rails/Rack and lots of other gems to find out why lines similar
> to that one was appearing.

I do in fact have rack-cache installed. I believe it is a dependency of
Rails 3.1.

>
> Add the following to your production.rb or development.rb file to get rid
> of the 'cache: ....' line
>
> config.action_dispatch.rack_cache = {:metastore => "rails:/", :entitystore
> => "rails:/", :verbose => false}

That did in fact get rid of the cache: line, but the problem remained. It
just remained silently.
It is a bit strange that, due to the many tortoises down there, it is not
even possible to know where this is coming from. Google seems to suggest
that I am an early sufferer, because the problem has not been dealt with
before (certainly not where Google can reach).

--
Revence

[Hongli Lai]

On Tue, Sep 20, 2011 at 5:37 PM, Revence Kalibwani <rev...@1st.ug> wrote:
> That did in fact get rid of the cache: line, but the problem remained. It
> just remained silently.
> It is a bit strange that, due to the many tortoises down there, it is not
> even possible to know where this is coming from. Google seems to suggest
> that I am an early sufferer, because the problem has not been dealt with
> before (certainly not where Google can reach).

Let's first figure out whether the request gets to the Ruby app at
all. If you restart Apache and access /, do you notice a small delay
caused by spawning the app?

[Revence Kalibwani]

Hello,

You seem to have scared it into working. Actually, it seems that running
a parallel `rails s` was interfering with it somehow. I had been running
`rails s` as some kind of control. (Since when did the control ever
interfere with the experiment? --Except in quantum mechanics, of
course?)
But it seems fine now; it would appear that stopping the other `rails s`
healed the problem. I have RackBaseURI / and RailsEnv development in the
conf.

[Hongli Lai]

On Wed, Sep 21, 2011 at 9:39 AM, Revence Kalibwani <rev...@1st.ug> wrote:
> Hello,
>
> You seem to have scared it into working. Actually, it seems that running
> a parallel `rails s` was interfering with it somehow. I had been running
> `rails s` as some kind of control. (Since when did the control ever
> interfere with the experiment? --Except in quantum mechanics, of
> course?)
> But it seems fine now; it would appear that stopping the other `rails s`
> healed the problem. I have RackBaseURI / and RailsEnv development in the
> conf.

That's the first time I've heard of 'rails s' interfering with Phusion
Passenger. :S Must be some kind of rack-cache state interference that
I don't know of.

[Revence Kalibwani]

Le Wednesday 21 September 2011 à 12:47 +0200, Hongli Lai a écrit :
> That's the first time I've heard of 'rails s' interfering with Phusion
> Passenger. :S Must be some kind of rack-cache state interference that
> I don't know of.

It may be that I am wrong about the cause-and-effect. I tweaked too many
things in desperation to be totally sure about this stuff.
Even so, Passenger **rocks**. :o) In fact, Rails has two epochs: BP and
AP. Before-Passenger, and After-Passenger.

--
Revence

[tsechingho]

Hi,

I got the same "cache: [GET /] miss" problem with nginx 1.0.6 or 1.1.4
+ passenger 3.0.9 + rails 3.1.0.
I try all the combination this thread told, and all failed.

But it is obvious the cache bug about rack_cache or rails 3.1.0 and
happened only in production environment.
So I add memcache-client to gemfile, bundle install, and KEEP USE
CACHE_STORE with FILE_STORE in production environment.

#config.cache_store = :mem_cache_store

Then the "cache: [GET /] miss" bug is gone, no more blank page.

I start to guess it may be the cache_store bug of rails 3.1 bug. An
rails ticket may be related:

https://rails.lighthouseapp.com/projects/8994/tickets/6780-actiondispatchrailsmetastore-returns-corrupt-rack-responses-with-memorystore

On Sep 19, 4:51 pm, Revence Kalibwani <reve...@1st.ug> wrote:
> And this is what the error log looks like, when a request has been
> made:
>
> [Mon Sep 19 11:36:22 2011] [notice] Apache/2.2.11 (FreeBSD) DAV/2 PHP/
> 5.2.9 with Suhosin-Patch Phusion_Passenger/3.0.9 mod_wsgi/2.8 Python/
> 2.7.2 mod_ruby/1.3.0 Ruby/1.8.7(2011-06-30) mod_ssl/2.2.11 OpenSSL/
> 0.9.8q configured -- resuming normal operations
> cache: [GET /] miss
>

[Revence Kalibwani]

Aha; I have solved this problem again and watched closely why it stopped
showing up.

In this case, the development database was not set up, and while `rails
s` showed the error in detail, the production app in Passenger showed
only what I described originally:
A 500 page, and cache [GET /] miss in the error log.
I created the database, and it went away.

[Andrew Shatnyy]

I've done all that's been advised here but nothing helped. :(
It was pretty hard to trace the issue since developing log wouldn't
show much to me.
I went ahead and lunched WEBrick in production mode and I found what
was causing that page problem.

There should be a way how to reset application cache.

[Revence Kalibwani]

Regarding this problem, the general solution should be considered like this: launch `rails s -e production` and the issues you see are the problem that is causing Passenger to act like that. Use `rails s -e production` to find the problem; it has worked well for me since I started doing it that way.

Also, regarding clearing caches, I still do a hacky `rm -rf tmp/cache/*` and also flushing the ones in public that are generated due to the caches_page directive (mine are usually cleared by `rm -rf public/en*`). I could probably use standard invalidation functions under `rails c`, but you're right, it should be nicer.

--
Revence
(Typed on mobile phone keyboard, so excuse any typos herein.
Rédigé avec clavier du téléphone; je m'excuse pour mes fautes d'orthographe qu'il y ait ci-dessus.)

-----Message d'origine-----
De:Andrew Shatnyy
Envoyé: 03/10/2011, 07:44
To: Phusion Passenger Discussions
Objet:[phusion-passenger] Re: cache: [GET /] miss

--

[Ayrton]

I have stumbled upon the same problem. This was a clean rails app (a
new one + one scaffold). And couldn't fix it with any of the
solutions in this thread.

As to the person who linked to the lighthouse ticket: this was
resolved according to the same GitHub issue: https://github.com/rails/rails/issues/545

[tsechingho]

I encounter this bug again when i start to deploy old app to new
server.

I find this combination is work well:

nginx 1.0.6 + passenger 3.0.9 + rails 3.1.0

, other versions newer than nginx 1.0.6 are broken.

just for your information.

[Rafael Schär]

I have the same behavior, Setup is:

- Apache
- Passenger (mod_rails) 3.0.9
- ruby 1.9.2-p290
- Rails 3.1.1
- RailsEnv, production

- Caching disalbed
or
- Caching enable with
config.cache_classes = true

# Full error reports are disabled and caching is turned on
config.consider_all_requests_local = true
config.action_controller.perform_caching = true

config.cache_store = :file_store, '#{RAILS_ROOT}/tmp/cache'
or
config.cache_store = :memory_store

[Revence Kalibwani]

Hello, Rafael!

Have you tried running the same site with `rails s -e production` ? Does
it work?

[Michael Svendsen]

Hi

I solved this problem by running

bundle exec rake assets:precompile

and then restart Apache.

/Michael

[purvez]

Hi

I've run into the same problem on a hosted Ubuntu 11.10 server. My
Rails 3.2 environment there is production. To try and understand
where the problem is I shutdown apache and started a WEBrick server as
per Revence's suggestion. I then made the following call:

curl http://0.0.0.0:3000

It served me a 404.html message and.... this is the interesting bit on
the WEBrick terminal it still showed

cache: [GET /] miss

Just so everyone understands I do have an index.html in my /public
directory with exactly the same access permissions as 404.html!!
So at least in my case it doesn't appear to be Phusion related but
something else. However I don't know how to find out what that is?

Any other ideas out there?

Thanks
Purvez

[Adam R. B. Jack]

Forgive me if I am missing an earlier part of a thread that says more, but is it just the error (warning) that you see? I get this (and a bunch more) w/ dalli/memcached configured. It looks in the memory cache for a key matching the page path, and logs this if it doesn't find it. Not sure why it is so verbose.

Reading you bit about /public/index.html, is that not being served? If not, maybe URL re-writing isn't configured/enabled?

Sorry if I just added noise not signal.

regards,

Adam

--
You received this message because you are subscribed to the Google Groups "Phusion Passenger Discussions" group.
To post to this group, send email to phusion-...@googlegroups.com.
To unsubscribe from this group, send email to phusion-passen...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/phusion-passenger?hl=en.

--

Find your nature: http://wildobs.com

[Ramsés López]

Hi all, just recently I into this problem... which was caused because I didn't have installed a javascript runtime (I installed node.js, sudo apt-get install nodejs).

I came across this solution by running

rails s -e production

Which still gave the cache: [GET] miss error.

Then I tried Michael Svendsen's solution, and that gave the warning that execjs didn't found any js runtime.

Hope this helps someone!

PD: thanks Michael!

[walt_die]

+1 

(ohh I'd wish for Passenger to give just a tad more info on that cache [GET:/] miss :)

/Walther

[Leonard Teo]

This was driving me crazy as well but it's actually not Phusion
Passenger, it's coming from Rails.

You'll get the cache misses if you set
config.action_controller.perform_caching = true (default setting on
production).

Try running rails server -e production and you'll see the cache misses
all coming through.

Here's the github issue:
https://github.com/rails/rails/issues/5245

Leo