8.9.3. The 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 config.ru.
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.

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:

9.2. Inspecting Phusion Passenger’s internal status

9.3. Debugging frozen applications

If one of your application processes is frozen (stopped responding), then you
can figure out where it is frozen by killing it with SIGABRT. This will cause the
processs to print a backtrace, after which it aborts. The backtrace information is
logged into the web server error log file.

In case of Ruby applications, you can also send the SIGQUIT signal to have it print
a backtrace without aborting.

Phusion Passenger automatically leverages operating system virtual memory copy-on-write features in order to reduce the memory usage of Ruby applications. Experience has shown that this reduces memory usage by 33% on average. For this mechanism to work, a Ruby interpreter with a copy-on-write friendly garbage collector is required. The following Ruby interpreters have copy-on-write friendly garbage collectors:

MRI Ruby >= 2.0. Versions prior to 2.0 did not have a copy-on-write friendly garbage collector.

Ruby Enterprise Edition, which was Phusion’s branch of MRI Ruby 1.8 with a copy-on-write friendly garbage collector and other enhancement. It has reached End-Of-Life as of 2012, but remains available for legacy systems.

10.5. Installing multiple Ruby on Rails versions

Each Ruby on Rails applications that are going to be deployed may require a
specific Ruby on Rails version. You can install a specific version with
this command:

gem install rails -v X.X.X

where X.X.X is the version number of Ruby on Rails.

All of these versions will exist in parallel, and will not conflict with each
other. Phusion Passenger will automatically make use of the correct version.

10.6. Making the application restart after each request

In some situations it might be desirable to restart the web application after
each request, for example when developing a non-Rails application that doesn’t
support code reloading, or when developing a web framework.

To achieve this, simply create the file tmp/always_restart.txt in your
application’s root folder. Unlike restart.txt, Phusion Passenger does not
check for this file’s timestamp: Phusion Passenger will always restart the
application, as long as always_restart.txt exists.

If you’re just developing a Rails application then you probably don’t need
this feature. If you set
RailsEnv development
in your web server configuration,
then Rails will automatically reload your application code after each request.
always_restart.txt is mostly useful when you’re using a web framework that
doesn’t support code reloading by itself, of when you’re working on a web framework
yourself.

10.7. How to fix broken images/CSS/JavaScript URIs in sub-URI deployments

Some people experience broken images and other broken static assets when they
deploy their application to a sub-URI (i.e. http://mysite.com/railsapp/).
The reason for this usually is that you used a
static URI for your image in the views. This means your img source probably refers
to something like /images/foo.jpg. The leading slash means that it’s an absolute URI:
you’re telling the browser to always load http://mysite.com/images/foo.jpg no
matter what. The problem is that the image is actually at
http://mysite.com/railsapp/images/foo.jpg. There are two ways to fix this.

The first way (not recommended) is to change your view templates to refer to
images/foo.jpg. This is a relative URI: note the lack of a leading slash). What
this does is making the path relative to the current URI. The problem is that if you
use restful URIs, then your images will probably break again when you add a level to
the URI.
For example, when you’re at http://mysite.com/railsapp the browser will look for
http://mysite.com/railsapp/images/foo.jpg. But when you’re at
http://mysite.com/railsapp/controller. the browser will look for
http://mysite.com/railsapp/controller/images/foo.jpg.
So relative URIs usually don’t work well with layout templates.

The second and highly recommended way is to always use Rails helper methods to
output tags for static assets. These helper methods automatically take care
of prepending the base URI that you’ve deployed the application to. For images
there is image_tag, for JavaScript there is javascript_include_tag and for
CSS there is stylesheet_link_tag. In the above example you would simply remove
the <img> HTML tag and replace it with inline Ruby like this:

<%= image_tag("foo.jpg") %>

This will generate the proper image tag to $RAILS_ROOT/public/images/foo.jpg
so that your images will always work no matter what sub-URI you’ve deployed to.

These helper methods are more valuable than you may think. For example they also
append a timestamp to the URI to better facilitate HTTP caching. For more information,
please refer to
the Rails API docs.

10.12. Upload progress

11. Under the hood

Phusion Passenger hides a lot of complexity for the end user (i.e. the web server
system administrator), but sometimes it is desirable to know what is going on.
This section describes a few things that Phusion Passenger does under the hood.

11.1. Page caching support

For each HTTP request, Phusion Passenger will automatically look for a corresponding
page cache file, and serve that if it exists. It does this by appending ".html" to
the filename that the URI normally maps to, and checking whether that file exists.
This check occurs after checking whether the original mapped filename exists (as part
of static asset serving). All this is done without the need for special mod_rewrite
rules.

For example, suppose that the browser requests /foo/bar.

Phusion Passenger will first check whether this URI maps to a static file, i.e.
whether the file foo/bar exists in the web application’s public directory.
If it does then Phusion Passenger will serve this file through the web server immediately.

If that doesn’t exist, then Phusion Passenger will check whether the file
foo/bar.html exists. If it does then Phusion Passenger will serve this file
through the web server immediately.

If foo/bar.html doesn’t exist either, then Phusion Passenger will forward the
request to the underlying web application.

Note that Phusion Passenger’s page caching support doesn’t work if your web
application uses a non-standard page cache directory, i.e. if it doesn’t cache to
the public directory. In that case you’ll need to use mod_rewrite to serve such
page cache files.

11.2.2. When the system has multiple Ruby interpreters

11.3. Static assets serving

Phusion Passenger accelerates serving of static files. This means that, if an URI
maps to a file that exists, then Phusion Passenger will let Apache serve that file
directly, without hitting the web application.

Phusion Passenger does all this without the need for any mod_rewrite rules. People
who are switching from an old Mongrel-based setup might have mod_rewrite rules such
as these:

13. Appendix B: Terminology

13.1. Application root

The root directory of an application that’s served by Phusion Passenger.

In case of Ruby on Rails applications, this is the directory that contains
Rakefile, app/, config/, public/, etc. In other words, the directory
pointed to by RAILS_ROOT. For example, take the following directory structure: