Phusion Passenger users guide, Nginx version

# Phusion Passenger users guide, Nginx version

Phusion Passenger is an Nginx module, which makes deploying Ruby and Ruby on Rails applications on Nginx a breeze. It follows the usual Ruby on Rails conventions, such as "Don’t-Repeat-Yourself" and ease of setup, while at the same time providing enough flexibility.

This users guide will teach you:

- How to install Nginx with Phusion Passenger support.

- How to configure Phusion Passenger.

- How to deploy a Ruby on Rails application.

- How to deploy a Rack-based Ruby application.

- How to solve common problems.

This guide assumes that the reader is somewhat familiar with Nginx and with using the commandline.

## 1. Support information

### 1.1. Supported operating systems

Phusion Passenger works on any POSIX-compliant operating system. In other words: practically any operating system on earth, except Microsoft Windows.

Phusion Passenger is confirmed on a large number of operating systems and Linux distributions, including, but not limited to, Ubuntu, Debian, CentOS/Fedora/RHEL, Gentoo, Mac OS X, FreeBSD and Solaris. Both 32-bit and 64-bit platforms are supported. Please report a bug or join our discussion forum if it doesn’t work on your POSIX-compliant operating system.

### 1.2. Where to get support

- Issue tracker - report bugs here.

- Discussion forum - post a message here if you’re experiencing problems.

## 2. Installing Phusion Passenger

### 2.1. Overview

As you might already know, Nginx does not support loadable modules, in contrast to most other web servers (e.g. Apache). Therefore, to install Phusion Passenger for Nginx, one must recompile and reinstall Nginx with Phusion Passenger support. There are two ways to do this:

1. By running the Phusion Passenger installer for Nginx. This installer will guide you through the entire installation process, including downloading, compiling and installing Nginx. You should be able to get Nginx with Phusion Passenger support up-and-running in a matter of minutes. This is the recommended installation method.

2. By manually configuring and compiling Nginx with Phusion Passenger support, through Nginx’s --add-module configure option. Generally, using our installer is easier, so you should only use this method if you’re already familiar with compiling Nginx.

| You might have to run the installation commands in the following sections as root. If the installer fails because of permission errors, it will tell you.

### 2.2. Specifying the correct Ruby installation

If your system has multiple Ruby installations — which is likely the case on MacOS X, or if you’ve also installed Ruby Enterprise Edition— then you will need to tell the operating system which Ruby installation to use, prior to running the Phusion Passenger installer. If you only have one Ruby installation (the case on most Linux systems), then you can skip this section because Phusion Passenger will automatically detect it.

To specify a Ruby installation, prepend your Ruby installation’s bin directory to the PATH environment variable. For example, if you have the following Ruby installations:

- /usr/bin/ruby

- /opt/myruby/bin/ruby

and you want to use the latter, then type:

    export PATH=/opt/myruby/bin:$PATH

### 2.3. Installing Phusion Passenger for Nginx through the installer

#### 2.3.1. Obtaining the Phusion Passenger files and running the installer

You must obtain the Phusion Passenger files in order to run the installer. This can be done either by installing the Phusion Passenger gem, or by downloading the source tarball.

##### Gem

First, install the Phusion Passenger gem by running:

    gem install passenger

Next, run the Phusion Passenger installer for Nginx:

    passenger-install-nginx-module

Please follow the instructions given by the installer.

##### Source tarball

The source tarball can be download from the Phusion Passenger website. Extract the tarball to whatever location you prefer. The Phusion Passenger files are to reside in that location permanently. For example, if you would like Phusion Passenger to reside in /opt/passenger-x.x.x, then type:

    cd /opt
    tar xzvf ~/YourDownloadsFolder/passenger-x.x.x.tar.gz

Next, run the Phusion Passenger installer for Nginx:

    /opt/passenger-x.x.x/bin/passenger-install-nginx-module

Please follow the instructions given by the installer.

| Please do not remove the passenger-x.x.x folder after installation. Furthermore, the passenger-x.x.x folder must be accessible by Nginx.

#### 2.3.2. Non-interactive/automatic installation

By default, the installer is interactive. If you want to automate installation, then you can do so by passing various answers to the installer through command line options.

Please run the installer with --help for a list of available command line options.

### 2.4. Installing Phusion Passenger for Nginx manually

You can also install Phusion Passenger the way you install any other Nginx module. To do this, run Nginx’s configure script with --add-module=/path-to-passenger-root/ext/nginx.

If you installed Phusion Passenger via the gem, then path-to-passenger-root can be obtained with the command:

    passenger-config --root

This will probably output something along the lines of /usr/lib/ruby/gems/1.8/gems/passenger-x.x.x, so you’ll probably have to specify something like --add-module=/usr/lib/ruby/gems/1.8/gems/passenger-x.x.x/ext/nginx.

If you installed Phusion Passenger via a source tarball, then path-to-passenger-root is the directory which contains the Phusion Passenger source code. So if you extracted the Phusion Passenger source code to /opt/passenger-x.x.x, then you’ll have to specify --add-module=/opt/passenger-x.x.x/ext/nginx.

After having installed Nginx with Phusion Passenger support, you must paste the following line into your Nginx configuration file:

    passenger_root /path-to-passenger-root;

After having done so, restart Nginx.

### 2.5. Upgrading or downgrading Phusion Passenger or Nginx itself

Whether you’re upgrading/downgrading Phusion Passenger or Nginx itself (or perhaps both), Nginx will have to be recompiled and reinstalled. The procedure is exactly the same as a normal installation so just follow the instructions in section 2.3 or 2.4.

When following the installation instructions, eventually passenger-install-nginx-module or this document will instruct you to copy & paste some settings into the Nginx configuration file; something that looks along the lines of:

    passenger_root ...;
    passenger_ruby ...;

Because you already had Phusion Passenger installed, you already had similar settings in your Nginx configuration file, just with different values. Replace the old settings with the new ones that you are instructed to paste. It is important that the old settings are removed, otherwise Phusion Passenger may malfunction.

When you’re done, restart Nginx.

### 2.6. Unloading (disabling) Phusion Passenger from Nginx without uninstalling it

You can temporarily unload (disable) Phusion Passenger from Nginx, without uninstalling the Phusion Passenger files, so that Nginx behaves as if Phusion Passenger was never installed in the first place. This might be useful to you if, for example, you seem to be experiencing a problem caused by Phusion Passenger, but you want to make sure whether that’s actually the case, without having to go through the hassle of uninstalling Phusion Passenger completely. When disabled, Phusion Passenger will not occupy any memory or CPU or otherwise interfere with Nginx.

To unload Phusion Passenger, edit your Nginx configuration file(s) and comment out all Phusion Passenger configuration directives.

For example, if your configuration file looks like this…

    ...

    http {
        passenger_root /somewhere/passenger-x.x.x;
        passenger_ruby /usr/bin/ruby;
        passenger_max_pool_size 10;

        gzip on;

        server {
            server_name www.foo.com;
            listen 80;
            root /webapps/foo/public;
            passenger_enabled on;
            passenger_use_global_queue on;
        }
    }

…then comment out the relevant directives, so that it looks like this:

    ...

    http {
        # passenger_root /somewhere/passenger-x.x.x;
        # passenger_ruby /usr/bin/ruby;
        # passenger_max_pool_size 10;

        gzip on;

        server {
            server_name www.foo.com;
            listen 80;
            root /webapps/foo/public;
            # passenger_enabled on;
            # passenger_use_global_queue on;
        }
    }

After you’ve done this, save the file and restart Nginx.

### 2.7. Uninstalling Phusion Passenger

To uninstall Phusion Passenger, please first remove all Phusion Passenger configuration directives from your Nginx configuration file(s). After you’ve done this, you need to remove the Phusion Passenger files.

- If you installed Phusion Passenger via a gem, then type gem uninstall passenger. You might have to run this as root.

- If you installed Phusion Passenger via a source tarball, then remove the directory in which you placed the extracted Phusion Passenger files. This directory is the same as the one pointed to the by PassengerRoot configuration directive.

After having done so, recompile and reinstall Nginx itself, this time without Phusion Passenger support, in order to purge any Phusion Passenger code from the Nginx binary.

## 3. Deploying a Ruby on Rails 1.x or 2.x (but NOT Rails >= 3) application

Suppose you have a Ruby on Rails application in /webapps/mycook, and you own the domain www.mycook.com. You can either deploy your application to the virtual host’s root (i.e. the application will be accessible from the root URL, http://www.mycook.com/), or in a sub URI (i.e. the application will be accessible from a sub URL, such as http://www.mycook.com/railsapplication).

| The default RAILS_ENV environment in which deployed Rails applications are run, is “production”. You can change this by changing the rails_env configuration option.

### 3.1. Deploying to a virtual host’s root

Add a server virtual host entry to your Nginx configuration file. The virtual host’s root must point to your Ruby on Rails application’s public folder.

Inside the server block, set passenger_enabled on.

For example:

    http {
        ...

        server {
            listen 80;
            server_name www.mycook.com;
            root /webapps/mycook/public;
            passenger_enabled on;
        }

        ...
    }

Then restart Nginx. The application has now been deployed.

### 3.2. Deploying to a sub URI

Suppose that you already have a server virtual host entry:

    http {
        ...

        server {
            listen 80;
            server_name www.phusion.nl;
            root /websites/phusion;
        }

        ...
    }

And you want your Ruby on Rails application to be accessible from the URL http://www.phusion.nl/rails.

To do this, make a symlink in the virtual host’s document root, and have it point to your Ruby on Rails application’s public folder. For example:

    ln -s /webapps/mycook/public /websites/phusion/rails

Next, set passenger_enabled on and add a passenger_base_uri option to the server block:

    http {
        ...

        server {
            listen 80;
            server_name www.phusion.nl;
            root /websites/phusion;
            passenger_enabled on;        # <--- These lines have
            passenger_base_uri /rails;   # <--- been added.
        }

        ...
    }

Then restart Nginx. The application has now been deployed.

You can deploy multiple Rails applications under a virtual host, by specifying passenger_base_uri multiple times. For example:

    server {
        ...
        passenger_base_uri /app1;
        passenger_base_uri /app2;
        passenger_base_uri /app3;
    }

### 3.3. Redeploying (restarting the Ruby on Rails application)

Deploying a new version of a Ruby on Rails application is as simple as re-uploading the application files, and restarting the application.

There are two ways to restart the application:

1. By restarting Nginx.

2. By creating or modifying the file tmp/restart.txt in the Rails application’s root folder. Phusion Passenger will automatically restart the application during the next request.

For example, to restart our example MyCook application, we type this in the command line:

    touch /webapps/mycook/tmp/restart.txt

Please note that, unlike earlier versions of Phusion Passenger, restart.txt is not automatically deleted. Phusion Passenger checks whether the timestamp of this file has changed in order to determine whether the application should be restarted.

### 3.4. Migrations

Phusion Passenger is not related to Ruby on Rails migrations in any way. To run migrations on your deployment server, please login to your deployment server (e.g. with ssh) and type rake db:migrate RAILS_ENV=production in a shell console, just like one would normally run migrations.

### 3.5. Capistrano integration

See Capistrano recipe.

## 4. Deploying a Rack-based Ruby application (including Rails >= 3)

Phusion Passenger supports arbitrary Ruby web applications that follow the Rack interface.

Phusion Passenger assumes that Rack application directories have a certain layout. Suppose that you have a Rack application in /webapps/rackapp. Then that folder must contain at least three entries:

- config.ru, a Rackup file for starting the Rack application. This file must contain the complete logic for initializing the application.

- public/, a folder containing public static web assets, like images and stylesheets.

- tmp/, used for restart.txt (our application restart mechanism). This will be explained in a following subsection.

So /webapps/rackapp must, at minimum, look like this:

    /webapps/rackapp
      |
      +-- config.ru
      |
      +-- public/
      |
      +-- tmp/

Suppose you own the domain www.rackapp.com. You can either deploy your application to the virtual host’s root (i.e. the application will be accessible from the root URL, http://www.rackapp.com/), or in a sub URI (i.e. the application will be accessible from a sub URL, such as http://www.rackapp.com/rackapp).

| The default RACK_ENV environment in which deployed Rack applications are run, is “production”. You can change this by changing the rack_env configuration option.

### 4.1. Tutorial/example: writing and deploying a Hello World Rack application

First we create a Phusion Passenger-compliant Rack directory structure:

    $ mkdir /webapps/rack_example
    $ mkdir /webapps/rack_example/public
    $ mkdir /webapps/rack_example/tmp

Next, we write a minimal "hello world" Rack application:

    $ cd /webapps/rack_example
    $ some_awesome_editor config.ru
    ...type in some source code...
    $ cat config.ru
    app = proc do |env|
        [200, { "Content-Type" => "text/html" }, ["hello <b>world</b>"]]
    end
    run app

Finally, we deploy it by adding the following configuration options to the Nginx configuration file:

    http {
        ...
        server {
            listen 80;
            server_name www.rackexample.com;
            root /webapps/rack_example/public;
            passenger_enabled on;
        }
        ...
    }

And we’re done! After an Nginx restart, the above Rack application will be available under the URL http://www.rackexample.com/.

### 4.2. Deploying to a virtual host’s root

Add a server virtual host entry to your Nginx configuration file. The virtual host’s root must point to your Rack application’s public folder. You must also set passenger_enabled on in the server block.

For example:

    http {
        ...
        server {
            listen 80;
            server_name www.rackapp.com;
            root /webapps/rackapp/public;
            passenger_enabled on;
        }
        ...
    }

Then restart Nginx. The application has now been deployed.

### 4.3. Deploying to a sub URI

Suppose that you already have a virtual host:

    http {
        ...

        server {
            listen 80;
            server_name www.phusion.nl;
            root /websites/phusion;
            passenger_enabled on;
        }

        ...
    }

And you want your Rack application to be accessible from the URL http://www.phusion.nl/rack.

To do this, make a symlink in the virtual host’s document root, and have it point to your Rack application’s public folder. For example:

    ln -s /webapps/rackapp/public /websites/phusion/rack

Next, set passenger_enabled on and add a passenger_base_uri option to the server block:

    http {
        ...

        server {
            listen 80;
            server_name www.phusion.nl;
            root /websites/phusion;
            passenger_enabled on;        # <--- These lines have
            passenger_base_uri /rack;    # <--- been added.
        }

        ...
    }

Then restart Nginx. The application has now been deployed.

You can deploy multiple Rack applications under a virtual host, by specifying passenger_base_uri multiple times. For example:

    server {
        ...
        passenger_base_uri /app1;
        passenger_base_uri /app2;
        passenger_base_uri /app3;
    }

### 4.4. Redeploying (restarting the Rack application)

Deploying a new version of a Rack application is as simple as re-uploading the application files, and restarting the application.

There are two ways to restart the application:

1. By restarting Nginx.

2. By creating or modifying the file tmp/restart.txt in the Rack application’s root folder. Phusion Passenger will automatically restart the application.

For example, to restart our example application, we type this in the command line:

    touch /webapps/rackapp/tmp/restart.txt

### 4.5. Rackup specifications for various web frameworks

This subsection shows example config.ru files for various web frameworks.

#### 4.5.1. Camping

    require 'rubygems'
    require 'rack'
    require 'camping'

    ##### Begin Camping application
    Camping.goes :Blog

    ...your application code here...
    ##### End Camping application

    run Rack::Adapter::Camping.new(Blog)

For Camping versions 2.0 and up, using run Blog as the final line will do.

#### 4.5.2. Halcyon

    require 'rubygems'
    require 'halcyon'
    $LOAD_PATH.unshift(Halcyon.root / 'lib')
    Halcyon::Runner.load_config Halcyon.root/'config'/'config.yml'
    run Halcyon::Runner.new

#### 4.5.3. Mack

    ENV["MACK_ENV"] = ENV["RACK_ENV"]
    load("Rakefile")
    require 'rubygems'
    require 'mack'
    run Mack::Utils::Server.build_app

#### 4.5.4. Merb

    require 'rubygems'
    require 'merb-core'

    Merb::Config.setup(
      :merb_root   => ::File.expand_path(::File.dirname(__FILE__)),
      :environment => ENV['RACK_ENV']
    )
    Merb.environment = Merb::Config[:environment]
    Merb.root = Merb::Config[:merb_root]
    Merb::BootLoader.run

    run Merb::Rack::Application.new

#### 4.5.5. Ramaze

    require "rubygems"
    require "ramaze"
    Ramaze.trait[:essentials].delete Ramaze::Adapter
    require "start"
    Ramaze.start!
    run Ramaze::Adapter::Base

#### 4.5.6. Sinatra

    require 'rubygems'
    require 'sinatra'
    require 'app.rb'

    run Sinatra::Application

## 5. Configuring Phusion Passenger

After installation, Phusion Passenger does not need any further configurations. Nevertheless, the system administrator may be interested in changing Phusion Passenger’s behavior. Phusion Passenger supports the following configuration options in the Nginx configuration file:

### 5.1. passenger_root <directory>

The location to the Phusion Passenger root directory. This configuration option is essential to Phusion Passenger, and allows Phusion Passenger to locate its own data files. The correct value is given by the installer.

If you’ve moved Phusion Passenger to a different directory then you need to update this option as well. Please read Moving Phusion Passenger to a different directory for more information.

This required option may only occur once, in the http configuration block.

### 5.2. passenger_ruby <filename>

This option allows one to specify the Ruby interpreter to use.

This option may only occur once, in the http configuration block. The default is ruby.

### 5.3. passenger_spawn_method <string>

"What spawn method should I use?"

This subsection attempts to describe spawn methods, but it’s okay if you don’t (want to) understand it, as it’s mostly a technical detail. You can basically follow this rule of thumb:

If your application works on Mongrel, but not on Phusion Passenger, then set passenger_spawn_method to conservative. Otherwise, leave it at smart-lv2 (the default).

However, we do recommend you to try to understand it. The smart and smart-lv2 spawn methods bring many benefits.

Internally, Phusion Passenger spawns multiple Ruby application processes in order to handle requests. But there are multiple ways with which processes can be spawned, each having its own set of pros and cons. Supported spawn methods are:

smart

  When this spawn method is used, Phusion Passenger will attempt to cache any framework code (e.g. Ruby on Rails itself) and application code for a limited period of time. Please read Spawning methods explained for a more detailed explanation of what smart spawning exactly does.

  Pros: This can significantly decrease spawn time (by as much as 90%). And, when Ruby Enterprise Edition is used, memory usage can be reduced by 33% on average.

  Cons: Some applications and libraries are not compatible with smart spawning. If that’s the case for your application, then you should use conservative as spawning method. Please read Spawning methods explained for possible compatibility issues.

smart-lv2

  This spawning method is similar to smart but it skips the framework spawner and uses the application spawner directly. This means the framework code is not cached between multiple applications, although it is still cached within instances of the same application. Please read Spawning methods explained for a more detailed explanation of what smart-lv2 spawning exactly does.

  Pros: It is compatible with a larger number of applications when compared to the smart method, and still performs some caching.

  Cons: It is slower than smart spawning if you have many applications which use the same framework version. It is therefore advised that shared hosts use the smart method instead.

conservative

  This spawning method is similar to the one used in Mongrel Cluster. It does not perform any code caching at all. Please read Spawning methods explained for a more detailed explanation of what conservative spawning exactly does.

  Pros: Conservative spawning is guaranteed to be compatible with all applications and libraries.

  Cons: Much slower than smart spawning. Every spawn action will be equally slow, though no slower than the startup time of a single server in Mongrel Cluster. Conservative spawning will also render Ruby Enterprise Edition’s memory reduction technology useless.

This option may occur in the following places:

- In the http configuration block.

- In a server configuration block.

- In a location configuration block.

- In an if configuration scope.

In each place, it may be specified at most once. The default value is smart-lv2.

### 5.4. passenger_rolling_restarts <on|off>

This feature is only available in Phusion Passenger Enterprise. It was introduced in version 3.0.0. Buy Phusion Passenger Enterprise here.

Enables or disables support for rolling restarts. Normally when you restart an application (by touching restart.txt), Phusion Passenger would shut down all application processes and spawn a new one. The spawning of a new application process could take a while, and any requests that come in during this time will be blocked until this first application process has spawned.

But when rolling restarts are enabled, Phusion Passenger Enterprise will:

1. Spawn a new process in the background.

2. When it’s done spawning, Phusion Passenger Enterprise will replace one of the old processes with this newly spawned one.

3. Step 1 and 2 are repeated until all processes have been replaced.

This way, visitors will not experience any delays when you are restarting your application. This allows you to, for example, upgrade your application often without degrading user experience.

Rolling restarts have a few caveat however that you should be aware of:

- Upgrading an application sometimes involves upgrading the database schema. With rolling restarts, there may be a point in time during which processes belonging to the previous version and processes belonging to the new version both exist at the same time. Any database schema upgrades you perform must therefore be backwards-compatible with the old application version.

- Because there’s no telling which process will serve a request, users may not see changes brought about by the new version until all processes have been restarted. It is for this reason that you should not use rolling restarts in development, only in production.

This option may occur in the following places:

- In the http configuration block.

- In a server configuration block.

- In a location configuration block.

- In an if configuration scope.

In each place, it may be specified at most once. The default value is off.

### 5.5. passenger_resist_deployment_errors <on|off>

This feature is only available in Phusion Passenger Enterprise. It was introduced in version 3.0.0. Buy Phusion Passenger Enterprise here.

Enables or disables resistance against deployment errors.

Suppose you’ve upgraded your application and you’ve issues a command to restart it (by touching restart.txt), but the application code contains an error that prevents Phusion Passenger from successfully spawning a process (e.g. a syntax error). Phusion Passenger would normally display an error message in response to this.

By enabling deployment error resistance, Phusion Passenger Enterprise would instead do this:

- It passes the request to one of the existing application processes (that belong to the previous version of the application). The visitor will not see a Phusion Passenger process spawning error message.

- It logs the error to the global web server error log file.

- It sets an internal flag so that no processes for this application will be spawned (even when the current traffic would normally result in more processes being spawned) and no processes will be idle cleaned. Processes could still be shutdown because of other events, e.g. because their memory limit have been reached.

This way, visitors will suffer minimally from deployment errors. Phusion Passenger will attempt to restart the application again next time restart.txt is touched.

Enabling deployment error resistance only works if rolling restart is also enabled.

This option may occur in the following places:

- In the http configuration block.

- In a server configuration block.

- In a location configuration block.

- In an if configuration scope.

In each place, it may be specified at most once. The default value is off.

### 5.6. Important deployment options

#### 5.6.1. passenger_enabled <on|off>

This option may be specified in the http configuration block, a server configuration block, a location configuration block or an if configuration scope, to enable or disable Phusion Passenger for that server or that location.

Phusion Passenger is disabled by default, so you must explicitly enable it for server blocks that you wish to serve through Phusion Passenger. Please see Deploying a Ruby on Rails application and Deploying a Rack-based Ruby application for examples.

#### 5.6.2. passenger_base_uri <uri>

Used to specify that the given URI is an distinct application that should be served by Phusion Passenger. This option can be used for both Rails and Rack applications. See Deploying Rails to a sub URI for an example.

It is allowed to specify this option multiple times. Do this to deploy multiple applications in different sub-URIs under the same virtual host.

This option may occur in the following places:

- In the http configuration block.

- In a server configuration block.

- In a location configuration block.

- In an if configuration scope.

### 5.7. Connection handling options

#### 5.7.1. passenger_use_global_queue <on|off>

Turns the use of global queuing on or off.

This option may occur in the following places:

- In the http configuration block.

- In a server configuration block.

- In a location configuration block.

- In an if configuration scope.

In each place, it may be specified at most once. The default value is on.

This feature is sponsored by 37signals.

What does this option do?

Recall that Phusion Passenger spawns multiple backend processes (e.g. multiple Ruby on Rails processes), each which processes HTTP requests serially. One of Phusion Passenger’s jobs is to forward HTTP requests to a suitable backend process. A backend process may take an arbitrary amount of time to process a specific HTTP request. If the websites are (temporarily) under high load, and the backend processes cannot process the requests fast enough, then some requests may have to be queued.

If global queuing is turned off, then Phusion Passenger will use fair load balancing. This means that each backend process will have its own private queue. Phusion Passenger will forward an HTTP request to the backend process that has the least amount of requests in its queue.

If global queuing is turned on, then Phusion Passenger will use a global queue that’s shared between all backend processes. If an HTTP request comes in, and all the backend processes are still busy, then Phusion Passenger will wait until at least one backend process is done, and will then forward the request to that process.

When to turn on global queuing?

You should turn on global queuing if one of your web applications may have long-running requests.

For example suppose that:

- global queuing is turned off.

- we’re currently in a state where all backend processes have 3 requests in their queue, except for a single backend process, which has 1 request in its queue.

The situation looks like this:

    Backend process A:  [*     ]  (1 request in queue)
    Backend process B:  [***   ]  (3 requests in queue)
    Backend process C:  [***   ]  (3 requests in queue)
    Backend process D:  [***   ]  (3 requests in queue)

Each process is currently serving short-running requests.

Phusion Passenger will forward the next request to backend process A. A will now have 2 items in its queue. We’ll mark this new request with an X:

    Backend process A:  [*X    ]  (2 request in queue)
    Backend process B:  [***   ]  (3 requests in queue)
    Backend process C:  [***   ]  (3 requests in queue)
    Backend process D:  [***   ]  (3 requests in queue)

Assuming that B, C and D still aren’t done with their current request, the next HTTP request - let’s call this Y - will be forwarded to backend process A as well, because it has the least number of items in its queue:

    Backend process A:  [*XY   ]  (3 requests in queue)
    Backend process B:  [***   ]  (3 requests in queue)
    Backend process C:  [***   ]  (3 requests in queue)
    Backend process D:  [***   ]  (3 requests in queue)

But if request X happens to be a long-running request that needs 60 seconds to complete, then we’ll have a problem. Y won’t be processed for at least 60 seconds. It would have been a better idea if Y was forward to processes B, C or D instead, because they only have short-living requests in their queues.

This problem will be avoided entirely if you turn global queuing on. With global queuing, all backend processes will share the same queue. The first backend process that becomes available will take from the queue, and so this “queuing-behind-long-running-request” problem will never occur.

#### 5.7.2. passenger_ignore_client_abort <on|off>

Normally, when the HTTP client aborts the connection (e.g. when the user clicked on "Stop" in the browser), the connection with the application process will be closed too. If the application process continues to send its response, then that will result in EPIPE errors in the application, which will be printed in the error log if the application doesn’t handle them gracefully.

If this option is turned on then upon client abort Phusion Passenger will continue to read the application process’s response while discarding all the read data. This prevents EPIPE errors but it’ll also mean the backend process will be unavailable for new requests until it is done sending its response.

This option may occur in the following places:

- In the http configuration block.

- In a server configuration block.

- In a location configuration block.

- In an if configuration scope.

In each place, it may be specified at most once. The default value is off.

#### 5.7.3. passenger_set_cgi_param <CGI environment name> <value>

Allows one to define additional CGI environment variables to pass to the backend application. This is equivalent to ngx_http_fastcgi_module’s fastcgi_param directive, and is comparable to ngx_http_proxy_module’s proxy_set_header option. Nginx variables in the value are interpolated.

For example:

    # Application will see a CGI environment "APP_NAME" with value "my super blog".
    passenger_set_cgi_param APP_NAME "my super blog";

    # Nginx variables are interpolated.
    passenger_set_cgi_param EXTRA_REQUEST_METHOD method=$request_method;

If you want to set an HTTP header, then you must set it in the CGI environment name format, i.e. HTTP_*:

    # !!!THIS IS WRONG!!! Don't do this!
    passenger_set_cgi_param X-Forwarded-For 127.0.0.2;

    # Instead, write it like this:
    passenger_set_cgi_param HTTP_X_FORWARDED_FOR 127.0.0.2;

This option may occur in the following places:

- In the http configuration block.

- In a server configuration block.

- In a location configuration block.

- In an if configuration scope.

#### 5.7.4. passenger_pass_header <header name>

Some headers generated by backend applications are not forwarded to the HTTP client, e.g. X-Accel-Redirect which is directly processed by Nginx and then discarded from the final response. This directive allows one to force Nginx to pass those headers anyway, similar to how proxy_pass_header works.

For example:

    location / {
       passenger_pass_header X-Accel-Redirect;
    }

This option may occur in the following places:

- In the http configuration block.

- In a server configuration block.

- In a location configuration block.

- In an if configuration scope.

#### 5.7.5. passenger_buffer_response <on|off>

When turned on, application-generated responses are buffered in memory and also on disk if the response is larger than a certain threshold. By buffering responses, protection is provided against slow HTTP clients that can not read your response immediately.

For example, consider an HTTP client that’s on a dial-up modem link, and your application process generates a 2 MB response. If response buffering is turned off then your application process will be blocked until the entire 2 MB has been sent out to the HTTP client. This disallows your application process to do any useful work in the mean time. By enabling response buffering, Phusion Passenger will read the application response as quickly as possible and will take care of slow clients.

However, keep in mind that enabling this option will make streaming responses impossible. Consider for example this piece of Rails code:

    render :text => lambda { |response, output|
        10.times do |i|
            output.write("entry #{i}\n")
            output.flush
            sleep 1
        end
    }

…or this piece of Rack code:

    class Response
        def each
            10.times do |i|
                yield("entry #{i}\n")
                sleep 1
            end
        end
    end

    app = lambda do |env|
        [200, { "Content-Type" => "text/plain" }, Response.new]
    end

When response buffering is turned on, Phusion Passenger will wait until the application is done sending the entire response before forwarding it to the client. The client will not receive anything for 10 seconds, after which it receives the entire response at once. When response buffering is turned off, it works as expected: the client receives an "entry X" message every second for 10 seconds.

This option may occur in the following places:

- In the http configuration block.

- In a server configuration block.

- In a location configuration block.

- In an if configuration scope.

In each place, it may be specified at most once. The default value is on.

#### 5.7.6. passenger_buffer_size

#### 5.7.7. passenger_buffers

#### 5.7.8. passenger_busy_buffer_size

These options have the same effect as proxy_module’s similarly named options. They can be used to modify the maximum allowed HTTP header size.

### 5.8. Security options

#### 5.8.1. passenger_user_switching <on|off>

Whether to enable user switching support.

This option may only occur once, in the http configuration block. The default value is on.

#### 5.8.2. passenger_user <username>

If user switching support is enabled, then Phusion Passenger will by default run the web application as the owner of the file config/environment.rb (for Rails apps) or config.ru (for Rack apps). This option allows you to override that behavior and explicitly set a user to run the web application as, regardless of the ownership of environment.rb/config.ru.

This option may occur in the following places:

- In the http configuration block.

- In a server configuration block.

- In a location configuration block.

- In an if configuration scope.

In each place, it may be specified at most once.

#### 5.8.3. passenger_group <group name>

If user switching support is enabled, then Phusion Passenger will by default run the web application as the primary group of the owner of the file config/environment.rb (for Rails apps) or config.ru (for Rack apps). This option allows you to override that behavior and explicitly set a group to run the web application as, regardless of the ownership of environment.rb/config.ru.

<group name> may also be set to the special value !STARTUP_FILE!, in which case the web application’s group will be set to environment.rb/config.ru's group.

This option may occur in the following places:

- In the http configuration block.

- In a server configuration block.

- In a location configuration block.

- In an if configuration scope.

In each place, it may be specified at most once.

#### 5.8.4. passenger_default_user <username>

Phusion Passenger enables user switching support by default. This configuration option allows one to specify the user that applications must run as, if user switching fails or is disabled.

This option may only occur once, in the http configuration block. The default value is nobody.

#### 5.8.5. Passenger_default_group <group name>

Phusion Passenger enables user switching support by default. This configuration option allows one to specify the group that applications must run as, if user switching fails or is disabled.

This option may only occur once, in the http configuration block. The default value is the primary group of the user specifified by passenger_default_user.

#### 5.8.6. passenger_friendly_error_pages <on|off>

Phusion Passenger can display friendly error pages whenever an application fails to start. This friendly error page presents the startup error message, some suggestions for solving the problem, and a backtrace. This feature is very useful during application development and useful for less experienced system administrators, but the page might reveal potentially sensitive information, depending on the application. Experienced system administrators who are using Phusion Passenger on serious production servers should consider turning this feature off.

This option may occur in the following places:

- In the http configuration block.

- In a server configuration block.

- In a location configuration block.

- In an if configuration scope.

In each place, it may be specified at most once. The default value is on.

### 5.9. Resource control and optimization options

#### 5.9.1. passenger_max_pool_size <integer>

The maximum number of application processes that may simultanously exist. A larger number results in higher memory usage, but improved ability to handle concurrent HTTP clients.

The optimal value depends on your system’s hardware and the server’s average load. You should experiment with different values. But generally speaking, the value should be at least equal to the number of CPUs (or CPU cores) that you have. If your system has 2 GB of RAM, then we recommend a value of 15. If your system is a Virtual Private Server (VPS) and has about 256 MB RAM, and is also running other services such as MySQL, then we recommend a value of 2.

If you find that your server is unable to handle the load on your Rails/Rack websites (i.e. running out of memory) then you should lower this value. (Though if your sites are really that popular, then you should strongly consider upgrading your hardware or getting more servers.)

This option may only occur once, in the http configuration bock. The default value is 6.

| We strongly recommend you to use Ruby Enterprise Edition. This allows you to reduce the memory usage of your Ruby on Rails applications by about 33%, and it’s not hard to install.

#### 5.9.2. passenger_min_instances <integer>

This specifies the minimum number of application processes that should exist for a given application. You should set this option to a non-zero value if you want to avoid potentially long startup times after a website has been idle for an extended period.

Please note that this option does not pre-start application processes during Nginx startup. It just makes sure that when the application is first accessed:

1. at least the given number of processes will be spawned.

2. the given number of processes will be kept around even when processes are being idle cleaned (see passenger_pool_idle_time).

If you want to pre-start application processes during Nginx startup, then you should use the passenger_pre_start directive, possibly in combination with passenger_min_instances. This behavior might seem counter-intuitive at first sight, but passenger_pre_start explains the rationale behind it.

For example, suppose that you have the following configuration:

    http {
        ...
        passenger_max_pool_size 15;
        passenger_pool_idle_time 10;

        server {
            listen 80;
            server_name foobar.com;
            root /webapps/foobar/public;
            passenger_min_instances 3;
        }
    }

When you start Nginx, there are 0 application processes for foobar.com. Things will stay that way until someone visits foobar.com. Suppose that there is only 1 visitor. 1 application process will be started immediately to serve the visitor, while 2 will be spawned in the background. After 10 seconds, when the idle timeout has been reached, these 3 application processes will not be cleaned up.

Now suppose that there’s a sudden spike of traffic, and 100 users visit foobar.com simultanously. Phusion Passenger will start 12 more application processes. After the idle timeout of 10 seconds have passed, Phusion Passenger will clean up 12 application processes, keeping 3 processes around.

The passenger_min_instances option may occur in the following places:

- In the http configuration block.

- In a server configuration block.

- In a location configuration block.

- In an if configuration scope.

In each place, it may be specified at most once. The default value is 1.

#### 5.9.3. passenger_max_instances <integer>

This feature is only available in Phusion Passenger Enterprise. It was introduced in version 3.0.0. Buy Phusion Passenger Enterprise here.

The maximum number of application processes that may simultaneously exist for an application. This helps to make sure that a single application will not occupy all available slots in the application pool.

This value must be less than passenger_max_pool_size. A value of 0 means that there is no limit placed on the number of processes a single application may spawn, i.e. only the global limit of passenger_max_pool_size will be enforced.

This option may occur in the following places:

- In the http configuration block.

- In a server configuration block.

- In a location configuration block.

- In an if configuration scope.

In each place, it may be specified at most once. The default value is 0.

Practical usage example

Suppose that you’re hosting two web applications on your server, a personal blog and an e-commerce website. You’ve set passenger_max_pool_size to 10. The e-commerce website is more important to you. You can then set passenger_max_instances to 3 for your blog, so that it will never spawn more than 3 processes, even if it suddenly gets a lot of traffic. Your e-commerce website on the other hand will be free to spawn up to 10 processes if it gets a lot of traffic.

#### 5.9.4. passenger_max_instances_per_app <integer>

The maximum number of application processes that may simultaneously exist for a single application. This helps to make sure that a single application will not occupy all available slots in the application pool.

This value must be less than passenger_max_pool_size. A value of 0 means that there is no limit placed on the number of processes a single application may use, i.e. only the global limit of passenger_max_pool_size will be enforced.

This option may only occur once, in the http configuration block. The default value is 0.

#### 5.9.5. passenger_pool_idle_time <integer>

The maximum number of seconds that an application process may be idle. That is, if an application process hasn’t received any traffic after the given number of seconds, then it will be shutdown in order to conserve memory.

Decreasing this value means that applications will have to be spawned more often. Since spawning is a relatively slow operation, some visitors may notice a small delay when they visit your Rails/Rack website. However, it will also free up resources used by applications more quickly.

The optimal value depends on the average time that a visitor spends on a single Rails/Rack web page. We recommend a value of 2 * x, where x is the average number of seconds that a visitor spends on a single Rails/Rack web page. But your mileage may vary.

When this value is set to 0, application processes will not be shutdown unless it’s really necessary, i.e. when Phusion Passenger is out of worker processes for a given application and one of the inactive application processes needs to make place for another application process. Setting the value to 0 is recommended if you’re on a non-shared host that’s only running a few applications, each which must be available at all times.

This option may only occur once, in the http configuration block. The default value is 300.

#### 5.9.6. passenger_max_requests <integer>

The maximum number of requests an application process will process. After serving that many requests, the application process will be shut down and Phusion Passenger will restart it. A value of 0 means that there is no maximum: an application process will thus be shut down when its idle timeout has been reached.

This option is useful if your application is leaking memory. By shutting it down after a certain number of requests, all of its memory is guaranteed to be freed by the operating system.

This option may occur in the following places:

- In the http configuration block.

- In a server configuration block.

- In a location configuration block.

- In an if configuration scope.

In each place, it may be specified at most once. The default value is 0.

| The passenger_max_requests directive should be considered as a workaround for misbehaving applications. It is advised that you fix the problem in your application rather than relying on these directives as a measure to avoid memory leaks.

#### 5.9.7. passenger_max_request_time <seconds>

This feature is only available in Phusion Passenger Enterprise. It was introduced in version 3.0.0. Buy Phusion Passenger Enterprise here.

The maximum amount of time, in seconds, that an application process may take to process a request. If the request takes longer than this amount of time, then the application process will be forcefully shut down, and possibly restarted upon the next request. A value of 0 means that there is no time limit.

This option is useful for preventing your application from freezing for an indefinite period of time.

This option may occur in the following places:

- In the http configuration block.

- In a server configuration block.

- In a location configuration block.

- In an if configuration scope.

In each place, it may be specified at most once. The default value is 0.

Example

Suppose that most of your requests are known to finish within 2 seconds. However, there is one URI, /expensive_computation, which is known to take up to 10 seconds. You can then configure Phusion Passenger as follows:

    server {
        listen 80;
        server_name www.example.com;
        root /webapps/my_app/public;
        passenger_enabled on;
        passenger_max_request_time 2;
        location /expensive_compuation {
            passenger_enabled on;
            passenger_max_request_time 10;
        }
    }

If a request to /expensive_computation takes more than 10 seconds, or if a request to any other URI takes more than 2 seconds, then the corresponding application process will be forced to shutdown.

| The passenger_max_request_time directive should be considered as a workaround for misbehaving applications. It is advised that you fix the problem in your application rather than relying on these directives as a measure to avoid freezing applications.

#### 5.9.8. passenger_memory_limit <integer>

This feature is only available in Phusion Passenger Enterprise. It was introduced in version 3.0.0. Buy Phusion Passenger Enterprise here.

The maximum amount of memory that an application process may use, in megabytes. Once an application process has surpassed its memory limit, it will process all the requests currently present in its queue and then shut down. A value of 0 means that there is no maximum: the application’s memory usage will not be checked.

This option is useful if your application is leaking memory. By shutting it down, all of its memory is guaranteed to be freed by the operating system.

This option may occur in the following places:

- In the http configuration block.

- In a server configuration block.

- In a location configuration block.

- In an if configuration scope.

In each place, it may be specified at most once. The default value is 200.

A word about permissions

The passenger_memory_limit directive requires that the user that the application is running as (see passenger_user_switching) to have access to the /proc file system, or to be able to inspect its status with ps (which on Linux and FreeBSD systems basically means the same thing, since ps reads process information from /proc). Therefore, on servers running with tight permissions on /proc, this directive may not work. If you wish to use this directive and your /proc permissions are too tight, then please consider untightening the permissions.

FreeBSD and /proc

On many FreeBSD systems, /proc is not mounted by default. /proc must be mounted in order for passenger_memory_limit to work.

It is also advised that you mount /proc with the linprocfs filesystem type instead of the regular FreeBSD proc filesystem type. The linprocfs filesystem type allows Phusion Passenger to read memory information from /proc directly, which is very fast. If you mount /proc with a different filesystem type, then Phusion Passenger must resort to querying memory information from the ps command, which is a lot slower.

| The passenger_max_requests and passenger_memory_limit directives should be considered as workarounds for misbehaving applications. It is advised that you fix the problem in your application rather than relying on these directives as a measure to avoid memory leaks.

#### 5.9.9. passenger_pre_start <url>

By default, Phusion Passenger does not start any application processes until said web application is first accessed. The result is that the first visitor of said web application might experience a small delay as Phusion Passenger is starting the web application on demand. If that is undesirable, then this directive can be used to pre-started application processes during Nginx startup.

A few things to be careful of:

- This directive accepts the URL of the web application you want to pre-start, not a on/off value! This might seem a bit weird, but read on for rationale. As for the specifics of the URL:

  - The domain part of the URL must be equal to the value of the server_name directive of the server block that defines the web application.

  - Unless the web application is deployed on port 80, the URL should contain the web application’s port number too.

  - The path part of the URL must point to some URI that the web application handles.

- You will probably want to combine this option with passenger_min_instances because application processes started with passenger_pre_start are subject to the usual idle timeout rules. See the example below for an explanation.

This option may only occur in the http configuration block. It may be specified any number of times.

##### Example 1: basic usage

Suppose that you have the following web applications.

    server {
        listen 80;
        server_name foo.com;
        root /webapps/foo/public;
        passenger_enabled on;
    }

    server {
        listen 3500;
        server_name bar.com;
        root /webapps/bar/public;
        passenger_enabled on;
    }

You want both of them to be pre-started during Nginx startup. The URL for foo.com is http://foo.com/ (or, equivalently, http://foo.com:80/) and the URL for bar.com is http://bar.com:3500/. So we add two passenger_pre_start directives, like this:

    server {
        listen 80;
        server_name foo.com;
        root /webapps/foo/public;
        passenger_enabled on;
    }

    server {
        listen 3500;
        server_name bar.com;
        root /webapps/bar/public;
        passenger_enabled on;
    }

    passenger_pre_start http://foo.com/;           # <--- added
    passenger_pre_start http://bar.com:3500/;      # <--- added

##### Example 2: pre-starting apps that are deployed in sub-URIs

Suppose that you have a web application deployed in a sub-URI /store, like this:

    server {
        listen 80;
        server_name myblog.com;
        root /webapps/wordpress;
        rails_base_uri /store;
    }

Then specify the server_name value followed by the sub-URI, like this:

    server {
        listen 80;
        server_name myblog.com;
        root /webapps/wordpress;
        rails_base_uri /store;
    }

    passenger_pre_start http://myblog.com/store;    # <----- added

The sub-URI must be included; if you don’t then the directive will have no effect. The following example is wrong and won’t pre-start the store web application:

    passenger_pre_start http://myblog.com/;    # <----- WRONG! Missing "/store" part.

##### Example 3: combining with passenger_min_instances

Application processes started with passenger_pre_start are also subject to the idle timeout rules as specified by passenger_pool_idle_time! That means that by default, the pre-started application processes for foo.com are bar.com are shut down after a few minutes of inactivity. If you don’t want that to happen, then you should combine passenger_pre_start with passenger_min_instances, like this:

    server {
        listen 80;
        server_name foo.com;
        root /webapps/foo/public;
        passenger_enabled on;
        passenger_min_instances 1;      # <--- added
    }

    server {
        listen 3500;
        server_name bar.com;
        root /webapps/bar/public;
        passenger_enabled on;
        passenger_min_instances 1;      # <--- added
    }

    passenger_pre_start http://foo.com/;
    passenger_pre_start http://bar.com:3500/;

##### So why a URL? Why not just an on/off flag?

A directive that accepts a simple on/off flag is definitely more intuitive, but due technical difficulties w.r.t. the way Nginx works, it’s very hard to implement it like that:

It is very hard to obtain a full list of web applications defined in the Nginx configuration file(s). In other words, it’s hard for Phusion Passenger to know which web applications are deployed on Nginx until a web application is first accessed, and without such a list Phusion Passenger wouldn’t know which web applications to pre-start. So as a compromise, we made it accept a URL.

##### What does Phusion Passenger do with the URL?

During Nginx startup, Phusion Passenger will send a dummy HEAD request to the given URL and discard the result. In other words, Phusion Passenger simulates a web access at the given URL. However this simulated request is always sent to localhost, not to the IP that the domain resolves to. Suppose that bar.com in example 1 resolves to 209.85.227.99; Phusion Passenger will send the following HTTP request to 127.0.0.1 port 3500 (and not to 209.85.227.99 port 3500):

    HEAD / HTTP/1.1
    Host: bar.com
    Connection: close

Similarly, for example 2, Phusion Passenger will send the following HTTP request to 127.0.0.1 port 80:

    HEAD /store HTTP/1.1
    Host: myblog.com
    Connection: close

##### Do I need to edit /etc/hosts and point the domain in the URL to 127.0.0.1?

No. See previous subsection.

##### My web application consists of multiple web servers. What URL do I need to specify, and in which web server’s Nginx config file?

Put the web application’s server_name value and the server block’s port in the URL, and put passenger_pre_start on all machines that you want to pre-start the web application on. The simulated web request is always sent to 127.0.0.1, with the domain name in the URL as value for the Host HTTP header, so you don’t need to worry about the request ending up at a different web server in the cluster.

##### Does passenger_pre_start support https:// URLs?

Yes. And it does not perform any certificate validation.

### 5.10. Logging and debugging options

#### 5.10.1. passenger_log_level <integer>

This option allows one to specify how much information Phusion Passenger should write to the Nginx error log file. A higher log level value means that more information will be logged.

Possible values are:

- 0: Show only errors and warnings.

- 1: Show the most important debugging information. This might be useful for system administrators who are trying to figure out the cause of a problem.

- 2: Show more debugging information. This is typically only useful for developers.

- 3: Show even more debugging information.

This option may only occur once, in the http configuration block. The default is 0.

#### 5.10.2. passenger_debug_log_file <filename>

By default Phusion Passenger debugging and error messages are written to the global web server error log. This option allows one to specify the file that debugging and error messages should be written to instead.

This option may only occur once, in the http configuration block.

#### 5.10.3. passenger_debugger <on|off>

This feature is only available in Phusion Passenger Enterprise. It was introduced in version 3.0.0. Buy Phusion Passenger Enterprise here.

Turns support for application debugging on or off. In case of Ruby applications, turning this option on will cause them to load the ruby-debug gem (when on Ruby 1.8) or the debugger gem (when on Ruby 1.9). If you’re using Bundler, you should add this to your Gemfile:

    gem 'ruby-debug', :platforms => :ruby_18
    gem 'debugger', :platforms => :ruby_19

Once debugging is turned on, you can use the command passenger-irb --debug <PID> to attach an rdebug console to the application process with the given PID. Attaching will succeed once the application process executes a debugger command.

This option may occur in the following places:

- In the http configuration block.

- In a server configuration block.

- In a location configuration block.

- In an if configuration scope.

In each place, it may be specified at most once. The default value is off.

### 5.11. Ruby on Rails-specific options

#### 5.11.1. rails_env <string>

This option allows one to specify the default RAILS_ENV value.

This option may occur in the following places:

- In the http configuration block.

- In a server configuration block.

- In a location configuration block.

- In an if configuration scope.

In each place, it may be specified at most once. The default value is production.

#### 5.11.2. rails_framework_spawner_idle_time <integer>

The FrameworkSpawner server (explained in Spawning methods explained) has an idle timeout, just like the backend processes spawned by Phusion Passenger do. That is, it will automatically shutdown if it hasn’t done anything for a given period.

This option allows you to set the FrameworkSpawner server’s idle timeout, in seconds. A value of 0 means that it should never idle timeout.

Setting a higher value will mean that the FrameworkSpawner server is kept around longer, which may slightly increase memory usage. But as long as the FrameworkSpawner server is running, the time to spawn a Ruby on Rails backend process only takes about 40% of the time that is normally needed, assuming that you’re using the smart spawning method. So if your system has enough memory, is it recommended that you set this option to a high value or to 0.

This option may occur in the following places:

- In the http configuration block.

- In a server configuration block.

- In a location configuration block.

- In an if configuration scope.

In each place, it may be specified at most once. The default value is 1800 (30 minutes).

#### 5.11.3. rails_app_spawner_idle_time <integer>

The ApplicationSpawner server (explained in Spawning methods explained) has an idle timeout, just like the backend processes spawned by Phusion Passenger do. That is, it will automatically shutdown if it hasn’t done anything for a given period.

This option allows you to set the ApplicationSpawner server’s idle timeout, in seconds. A value of 0 means that it should never idle timeout.

Setting a higher value will mean that the ApplicationSpawner server is kept around longer, which may slightly increase memory usage. But as long as the ApplicationSpawner server is running, the time to spawn a Ruby on Rails backend process only takes about 10% of the time that is normally needed, assuming that you’re using the smart or smart-lv2 spawning method. So if your system has enough memory, is it recommended that you set this option to a high value or to 0.

This option may occur in the following places:

- In the http configuration block.

- In a server configuration block.

- In a location configuration block.

- In an if configuration scope.

In each place, it may be specified at most once. The default value is 600 (10 minutes).

### 5.12. Rack and Rails >= 3 specific options

#### 5.12.1. rack_env <string>

This option allows one to specify the default RACK_ENV value.

This option may occur in the following places:

- In the http configuration block.

- In a server configuration block.

- In a location configuration block.

- In an if configuration scope.

In each place, it may be specified at most once. The default value is production.

### 5.13. Deprecated options

The following options have been deprecated, but are still supported for backwards compatibility reasons.

#### 5.13.1. rails_spawn_method

Deprecated in favor of passenger_spawn_method.

## 6. Analysis and system maintenance

Phusion Passenger provides a set of tools, which are useful for system analysis, maintenance and troubleshooting.

### 6.1. Inspecting memory usage

Process inspection tools such as ps and top are useful, but they rarely show the correct memory usage. The real memory usage is usually lower than what ps and top report.

There are many technical reasons why this is so, but an explanation is beyond the scope of this Users Guide. We kindly refer the interested reader to operating systems literature about virtual memory and copy-on-write.

The tool passenger-memory-stats allows one to easily analyze Phusion Passenger’s and Apache’s real memory usage. For example:

    [bash@localhost root]# passenger-memory-stats
    ------------- Apache processes --------------.
    PID    PPID  Threads  VMSize   Private  Name
    ---------------------------------------------.
    5947   1     9        90.6 MB  0.5 MB   /usr/sbin/apache2 -k start
    5948   5947  1        18.9 MB  0.7 MB   /usr/sbin/fcgi-pm -k start
    6029   5947  1        42.7 MB  0.5 MB   /usr/sbin/apache2 -k start
    6030   5947  1        42.7 MB  0.5 MB   /usr/sbin/apache2 -k start
    6031   5947  1        42.5 MB  0.3 MB   /usr/sbin/apache2 -k start
    6033   5947  1        42.5 MB  0.4 MB   /usr/sbin/apache2 -k start
    6034   5947  1        50.5 MB  0.4 MB   /usr/sbin/apache2 -k start
    23482  5947  1        82.6 MB  0.4 MB   /usr/sbin/apache2 -k start
    ### Processes: 8
    ### Total private dirty RSS: 3.50 MB

    --------- Passenger processes ---------.
    PID    Threads  VMSize   Private  Name
    ---------------------------------------.
    6026   1        10.9 MB  4.7 MB   Passenger spawn server
    23481  1        26.7 MB  3.0 MB   Passenger FrameworkSpawner: 2.0.2
    23791  1        26.8 MB  2.9 MB   Passenger ApplicationSpawner: /var/www/projects/app1-foobar
    23793  1        26.9 MB  17.1 MB  Rails: /var/www/projects/app1-foobar
    ### Processes: 4
    ### Total private dirty RSS: 27.76 M

The Private or private dirty RSS field shows the real memory usage of processes. Here, we see that all the Apache worker processes only take less than 1 MB memory each. This is a lot less than the 50 MB-ish memory usage as shown in the VMSize column (which is what a lot of people think is the real memory usage, but is actually not).

| Private dirty RSS reporting only works on Linux. Unfortunately other operating systems don’t provide facilities for determining processes' private dirty RSS. On non-Linux systems, the Resident Set Size is reported instead.

### 6.2. Inspecting Phusion Passenger’s internal status

One can inspect Phusion Passenger’s internal status with the tool passenger-status. This tool must typically be run as root. For example:

    [bash@localhost root]# passenger-status
    ----------- General information -----------
    max      = 6
    count    = 1
    active   = 0
    inactive = 1

    ----------- Domains -----------
    /var/www/projects/app1-foobar:
      PID: 9617      Sessions: 0    Processed: 7       Uptime: 2m 23s

The general information section shows the following information:

max

  The maximum number of application instances that Phusion Passenger will spawn. This equals the value given for PassengerMaxPoolSize (Apache) or passenger_max_pool_size (Nginx).

count

  The number of application instances that are currently alive. This value is always less than or equal to max.

active

  The number of application instances that are currently processing requests. This value is always less than or equal to count.

inactive

  The number of application instances that are currently not processing requests, i.e. are idle. Idle application instances will be shutdown after a while, as can be specified with PassengerPoolIdleTime (Apache)/passenger_pool_idle_time (Nginx) (unless this value is set to 0, in which case application instances are never shut down via idle time). The value of inactive equals count - active.

The domains section shows, for each application directory, information about running application instances:

Sessions

  Shows how many HTTP client are currently in the queue of that application Instance, waiting to be processed.

Processed

  Indicates how many requests the instance has served until now. Tip: it’s possible to limit this number with the PassengerMaxRequests configuration directive.

Uptime

  Shows for how long the application instance has been running.

Since Phusion Passenger uses fair load balancing by default, the number of sessions for the application instances should be fairly close to each other. For example, this is fairly normal:

      PID: 4281      Sessions: 2      Processed: 7      Uptime: 5m 11s
      PID: 4268      Sessions: 0      Processed: 5      Uptime: 4m 52s
      PID: 4265      Sessions: 1      Processed: 6      Uptime: 5m 38s
      PID: 4275      Sessions: 1      Processed: 7      Uptime: 3m 14s

But if you see a "spike", i.e. an application instance has an unusually high number of sessions compared to the others, then there might be a problem:

      PID: 4281      Sessions: 2      Processed: 7      Uptime: 5m 11s
      PID: 17468     Sessions: 8 <-+  Processed: 2      Uptime: 4m 47s
      PID: 4265      Sessions: 1   |  Processed: 6      Uptime: 5m 38s
      PID: 4275      Sessions: 1   |  Processed: 7      Uptime: 3m 14s
                                   |
                                   +---- "spike"

Possible reasons why spikes can occur:

1. Your application is busy processing a request that takes a very long time. If this is the case, then you might want to turn global queuing on.

2. Your application is frozen, i.e. has stopped responding. See Debugging frozen applications for tips.

### 6.3. Debugging frozen applications

If one of your application instances is frozen (stopped responding), then you can figure out where it is frozen by killing it with SIGABRT. This will cause the application to raise an exception, with a backtrace.

The exception (with full backtrace information) is normally logged into the Apache error log. But if your application or if its web framework has its own exception logging routines, then exceptions might be logged into the application’s log files instead. This is the case with Ruby on Rails. So if you kill a Ruby on Rails application with SIGABRT, please check the application’s production.log first (assuming that you’re running it in a production environment). If you don’t see a backtrace there, check the Apache error log.

| It is safe to kill application instances, even in live environments. Phusion Passenger will restart killed application instances, as if nothing bad happened.

### 6.4. Accessing individual application processes

When a request is sent to the web server, Phusion Passenger will automatically forward the request to the most suitable application process, but sometimes it is desirable to be able to directly access the individual application processes. Use cases include, but are not limited to:

- One wants to debug a memory leak or memory bloat problem that only seems to appear on certain URIs. One can send a request to a specific process to see whether that request causes the process’s memory usage to rise.

- The application caches data in local memory, and one wants to tell a specific application process to clear that local data.

- Other debugging use cases.

All individual application processes are accessible via HTTP, so you can use standard HTTP tools like curl. The exact addresses can be obtained with the command passenger-status --verbose. These sockets are all bound to 127.0.0.1, but the port number is dynamically assigned. As a security measure, the sockets are also protected with a process-specific random password, which you can see in the passenger-status --verbose output. This password must be sent through the “X-Passenger-Connect-Password” HTTP header.

Example:

    bash# passenger-status --verbose
    ----------- General information -----------
    max      = 6
    count    = 2
    active   = 0
    inactive = 2
    Waiting on global queue: 0

    ----------- Application groups -----------
    /Users/hongli/Sites/rack.test:
      App root: /Users/hongli/Sites/rack.test
      * PID: 24235   Sessions: 0    Processed: 7       Uptime: 17s
          URL     : http://127.0.0.1:58122
          Password: nFfVOX1F8LjZ90HJh28Sd_htJOsgRsNne2QXKf8NIXw
      * PID: 24250   Sessions: 0    Processed: 4       Uptime: 1s
          URL     : http://127.0.0.1:57933
          Password: _RGXlQ9EGDGJKLevQ_qflUtF1KmxEo2UiRzMwIE1sBY

Here we see that the web application rack.test has two processes. Process 24235 is accessible via http://127.0.0.1:58122, and process 24250 is accessible via http://127.0.0.1:57933.

To access 24235 we must send its password, nFfVOX1F8LjZ90HJh28Sd_htJOsgRsNne2QXKf8NIXw, through the X-Passenger-Connect-Password HTTP header, like this:

    bash# curl -H "X-Passenger-Connect-Password: nFfVOX1F8LjZ90HJh28Sd_htJOsgRsNne2QXKf8NIXw" http://127.0.0.1:58122/

### 6.5. Attaching an IRB console to an application process

Available in Phusion Passenger Enterprise since version 3.0.0.

You can attach an IRB console to any application process and inspect its state by executing arbitrary Ruby code. Do this by invoking passenger-irb <PID> where <PID> is the PID of the application process you wish to inspect. Note that the IRB console is currently only available for Ruby apps, not for apps in any other languages.

## 7. Tips

### 7.1. User switching (security)

There is a problem that plagues most PHP web hosts, namely the fact that all PHP applications are run in the same user context as the web server. So for example, Joe’s PHP application will be able to read Jane’s PHP application’s passwords. This is obviously undesirable on many servers.

Phusion Passenger solves this problem by implementing user switching. A Rails application is started as the owner of the file config/environment.rb, and a Rack application is started as the owner of the file config.ru. So if /home/webapps/foo/config/environment.rb is owned by joe, then Phusion Passenger will launch the corresponding Rails application as joe as well.

This behavior is the default, and you don’t need to configure anything. But there are things that you should keep in mind:

- The owner of environment.rb/config.ru must have read access to the application’s root directory, and read/write access to the application’s logs directory.

- This feature is only available if Apache is started by root. This is the case on most Apache installations.

- Under no circumstances will applications be run as root. If environment.rb/config.ru is owned as root or by an unknown user, then the Rails/Rack application will run as the user specified by passenger_default_user and passenger_default_group.

User switching can be disabled with the passenger_user_switching option.

### 7.2. Reducing memory consumption of Ruby on Rails applications by 33%

Is it possible to reduce memory consumption of your Rails applications by 33% on average, by using Ruby Enterprise Edition. Please visit the website for details.

Note that this feature does not apply to Rack applications.

### 7.3. Capistrano recipe

Phusion Passenger can be combined with Capistrano. The following Capistrano recipe demonstrates Phusion Passenger support. It assumes that you’re using Git as version control system.

    set :application, "myapp"
    set :domain,      "example.com"
    set :repository,  "ssh://#{domain}/path-to-your-git-repo/#{application}.git"
    set :use_sudo,    false
    set :deploy_to,   "/path-to-your-web-app-directory/#{application}"
    set :scm,         "git"

    role :app, domain
    role :web, domain
    role :db,  domain, :primary => true

    namespace :deploy do
      task :start, :roles => :app do
        run "touch #{current_release}/tmp/restart.txt"
      end

      task :stop, :roles => :app do
        # Do nothing.
      end

      desc "Restart Application"
      task :restart, :roles => :app do
        run "touch #{current_release}/tmp/restart.txt"
      end
    end

### 7.4. Bundler support

Phusion Passenger has automatic support for Bundler. It works as follows:

- If you have a .bundle/environment.rb in your application root, then Phusion Passenger will require that file before loading your application.

- Otherwise, if you have a Gemfile, then Phusion Passenger will automatically call Bundler.setup() before loading your application.

It’s possible that your application also calls Bundler.setup during loading, e.g. in config.ru or in config/boot.rb. This is the case with Rails 3, and is also the case if you modified your config/boot.rb according to the Bundler Rails 2.3 instructions. This leads to Bundler.setup being called twice, once before the application startup file is required and once during application startup. However this is harmless and doesn’t have any negative effects.

Phusion Passenger assumes that you’re using Bundler >= 0.9.5. If you don’t want Phusion Passenger to run its Bundler support code, e.g. because you need to use an older version of Bundler with an incompatible API or because you use a system other than Bundler, then you can override Phusion Passenger’s Bundler support code by creating a file config/setup_load_paths.rb. If this file exists then it will be required before loading the application startup file. In this file you can do whatever you need to setup Bundler or a similar system.

### 7.5. Moving Phusion Passenger to a different directory

It is possible to relocate the Phusion Passenger files to a different directory. It involves two steps:

1. Moving the directory.

2. Updating the “PassengerRoot” configuration option in Apache.

For example, if Phusion Passenger is located in /opt/passenger/, and you’d like to move it to /usr/local/passenger/, then do this:

1. Run the following command:

       mv /opt/passenger /usr/local/passenger

2. Edit your Apache configuration file, and set:

       PassengerRoot /usr/local/passenger

### 7.6. 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.

### 7.7. 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 Apache configuration, then Rails will automatically reload your application code after each request. always_restart.txt is only useful if you’re working on Ruby on Rails itself, or when you’re not developing a Rails application and your web framework does not support code reloading.

### 7.8. 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.

## 8. 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.

### 8.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.

1. 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 Apache immediately.

2. 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 Apache immediately.

3. 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.

### 8.2. How Phusion Passenger detects whether a virtual host is a web application

After you’ve read the deployment instructions you might wonder how Phusion Passenger knows that the server root points to a web application that Phusion Passenger is able to serve, and how it knows what kind of web application it is (e.g. Rails or Rack).

Phusion Passenger checks whether the virtual host is a Rails application by checking whether the following file exists:

    dirname(DocumentRoot) + "/config/environment.rb"

If you’re not a programmer and don’t understand the above pseudo-code snippet, it means that Phusion Passenger will:

1. Extract the parent directory filename from the value of the “root” directive.

2. Append the text "/config/environment.rb" to the result, and check whether the resulting filename exists.

So suppose that your server root is /webapps/foo/public. Phusion Passenger will check whether the file /webapps/foo/config/environment.rb exists.

Note that Phusion Passenger for Nginx does not resolve any symlinks in the root path. So for example, suppose that your root points to /home/www/example.com, which in turn is a symlink to /webapps/example.com/public. Phusion Passenger for Nginx will check for /home/www/config/environment.rb, not /webapps/example.com/config/environment.rb. This file of course doesn’t exist, and as a result Phusion Passenger will not activate itself for this virtual host, and you’ll most likely see some output generated by the Nginx default directory handler such as a Forbidden error message.

Detection of Rack applications happens through the same mechanism, exception that Phusion Passenger will look for config.ru instead of config/environment.rb.

## 9. Appendix A: About this document

The text of this document is licensed under the Creative Commons Attribution-Share Alike 3.0 Unported License.

Phusion Passenger is brought to you by Phusion.

Phusion Passenger is a trademark of Hongli Lai & Ninh Bui.

## 10. Appendix B: Terminology

### 10.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:

    /apps/foo/       <------ This is the Rails application's application root!
       |
       +- app/
       |   |
       |   +- controllers/
       |   |
       |   +- models/
       |   |
       |   +- views/
       |
       +- config/
       |   |
       |   +- environment.rb
       |   |
       |   +- ...
       |
       +- public/
       |   |
       |   +- ...
       |
       +- ...

In case of Rack applications, this is the directory that contains config.ru. For example, take the following directory structure:

    /apps/bar/      <----- This is the Rack application's application root!
       |
       +- public/
       |    |
       |    +- ...
       |
       +- config.ru
       |
       +- ...

In case of Python (WSGI) applications, this is the directory that contains passenger_wsgi.py. For example, take the following directory structure:

    /apps/baz/      <----- This is the WSGI application's application root!
       |
       +- public/
       |    |
       |    +- ...
       |
       +- passenger_wsgi.py
       |
       +- ...

### 10.2. Idle process

An "idle process" refers to a process that hasn’t processed any requests for a while.

### 10.3. Inactive process

An "inactive process" refers to a process that’s current not processing any requests. An idle process is always inactive, but an inactive process is not always considered idle.

## 11. Appendix C: Spawning methods explained

At its core, Phusion Passenger is an HTTP proxy and process manager. It spawns Ruby on Rails/Rack/WSGI worker processes (which may also be referred to as backend processes), and forwards incoming HTTP request to one of the worker processes.

While this may sound simple, there’s not just one way to spawn worker processes. Let’s go over the different spawning methods. For simplicity’s sake, let’s assume that we’re only talking about Ruby on Rails applications.

### 11.1. The most straightforward and traditional way: conservative spawning

Phusion Passenger could create a new Ruby process, which will then load the Rails application along with the entire Rails framework. This process will then enter an request handling main loop.

This is the most straightforward way to spawn worker processes. If you’re familiar with the Mongrel application server, then this approach is exactly what mongrel_cluster performs: it creates N worker processes, each which loads a full copy of the Rails application and the Rails framework in memory. The Thin application server employs pretty much the same approach.

Note that Phusion Passenger’s version of conservative spawning differs slightly from mongrel_cluster. Mongrel_cluster creates entirely new Ruby processes. In programmers jargon, mongrel_cluster creates new Ruby processes by forking the current process and exec()-ing a new Ruby interpreter. Phusion Passenger on the other hand creates processes that reuse the already loaded Ruby interpreter. In programmers jargon, Phusion Passenger calls fork(), but not exec().

### 11.2. The smart spawning method

| Smart spawning is supported for all Ruby applications but not for WSGI applications.

While conservative spawning works well, it’s not as efficient as it could be because each worker process has its own private copy of the Rails application as well as the Rails framework. This wastes memory as well as startup time.

Figure: Worker processes and conservative spawning. Each worker process has its own private copy of the application code and Rails framework code.

It is possible to make the different worker processes share the memory occupied by application and Rails framework code, by utilizing so-called copy-on-write semantics of the virtual memory system on modern operating systems. As a side effect, the startup time is also reduced. This is technique is exploited by Phusion Passenger’s smart and smart-lv2 spawn methods.

#### 11.2.1. How it works

When the smart-lv2 spawn method is being used, Phusion Passenger will first create a so-called ApplicationSpawner server process. This process loads the entire Rails application along with the Rails framework, by loading environment.rb. Then, whenever Phusion Passenger needs a new worker process, it will instruct the ApplicationSpawner server to do so. The ApplicationSpawner server will create a worker new process that reuses the already loaded Rails application/framework. Creating a worker process through an already running ApplicationSpawner server is very fast, about 10 times faster than loading the Rails application/framework from scratch. If the Ruby interpreter is copy-on-write friendly (that is, if you’re running Ruby Enterprise Edition) then all created worker processes will share as much common memory as possible. That is, they will all share the same application and Rails framework code.

Figure: Worker processes and the smart-lv2 spawn method. All worker processes, as well as the ApplicationSpawner, share the same application code and Rails framework code.

The smart spawn method goes even further, by caching the Rails framework in another process called the FrameworkSpawner server. This process only loads the Rails framework, not the application. When a FrameworkSpawner server is instructed to create a new worker process, it will create a new ApplicationSpawner to which the instruction will be delegated. All those ApplicationSpawner servers, as well as all worker processes created by those ApplicationSpawner servers, will share the same Rails framework code.

The smart-lv2 method allows different worker processes that belong to the same application to share memory. The smart method allows different worker processes - that happen to use the same Rails version - to share memory, even if they don’t belong to the same application.

Notes:

- Vendored Rails frameworks cannot be shared by different applications, even if both vendored Rails frameworks are the same version. So for efficiency reasons we don’t recommend vendoring Rails.

- ApplicationSpawner and FrameworkSpawner servers have an idle timeout just like worker processes. If an ApplicationSpawner/FrameworkSpawner server hasn’t been instructed to do anything for a while, it will be shutdown in order to conserve memory. This idle timeout is configurable.

#### 11.2.2. Summary of benefits

Suppose that Phusion Passenger needs a new worker process for an application that uses Rails 2.2.1.

- If the smart-lv2 spawning method is used, and an ApplicationSpawner server for this application is already running, then worker process creation time is about 10 times faster than conservative spawning. This worker process will also share application and Rails framework code memory with the ApplicationSpawner server and the worker processes that had been spawned by this ApplicationSpawner server.

- If the smart spawning method is used, and a FrameworkSpawner server for Rails 2.2.1 is already running, but no ApplicationSpawner server for this application is running, then worker process creation time is about 2 times faster than conservative spawning. If there is an ApplicationSpawner server for this application running, then worker process creation time is about 10 times faster. This worker process will also share application and Rails framework code memory with the ApplicationSpawner and FrameworkSpawner servers.

You could compare ApplicationSpawner and FrameworkSpawner servers with stem cells, that have the ability to quickly change into more specific cells (worker process).

In practice, the smart spawning methods could mean a memory saving of about 33%, assuming that your Ruby interpreter is copy-on-write friendly.

Of course, smart spawning is not without gotchas. But if you understand the gotchas you can easily reap the benefits of smart spawning.

### 11.3. Smart spawning gotcha #1: unintentional file descriptor sharing

Because worker processes are created by forking from an ApplicationSpawner server, it will share all file descriptors that are opened by the ApplicationSpawner server. (This is part of the semantics of the Unix fork() system call. You might want to Google it if you’re not familiar with it.) A file descriptor is a handle which can be an opened file, an opened socket connection, a pipe, etc. If different worker processes write to such a file descriptor at the same time, then their write calls will be interleaved, which may potentially cause problems.

The problem commonly involves socket connections that are unintentionally being shared. You can fix it by closing and reestablishing the connection when Phusion Passenger is creating a new worker process. Phusion Passenger provides the API call PhusionPassenger.on_event(:starting_worker_process) to do so. So you could insert the following code in your environment.rb:

    if defined?(PhusionPassenger)
        PhusionPassenger.on_event(:starting_worker_process) do |forked|
            if forked
                # We're in smart spawning mode.
                ... code to reestablish socket connections here ...
            else
                # We're in conservative spawning mode. We don't need to do anything.
            end
        end
    end

Note that Phusion Passenger automatically reestablishes the connection to the database upon creating a new worker process, which is why you normally do not encounter any database issues when using smart spawning mode.

#### 11.3.1. Example 1: Memcached connection sharing (harmful)

Suppose we have a Rails application that connects to a Memcached server in environment.rb. This causes the ApplicationSpawner to have a socket connection (file descriptor) to the Memcached server, as shown in the following figure:

    +--------------------+
    | ApplicationSpawner |-----------[Memcached server]
    +--------------------+

Phusion Passenger then proceeds with creating a new Rails worker process, which is to process incoming HTTP requests. The result will look like this:

    +--------------------+
    | ApplicationSpawner |------+----[Memcached server]
    +--------------------+      |
                                |
    +--------------------+      |
    | Worker process 1   |-----/
    +--------------------+

Since a fork() makes a (virtual) complete copy of a process, all its file descriptors will be copied as well. What we see here is that ApplicationSpawner and Worker process 1 both share the same connection to Memcached.

Now supposed that your site gets Slashdotted and Phusion Passenger needs to spawn another worker process. It does so by forking ApplicationSpawner. The result is now as follows:

    +--------------------+
    | ApplicationSpawner |------+----[Memcached server]
    +--------------------+      |
                                |
    +--------------------+      |
    | Worker process 1   |-----/|
    +--------------------+      |
                                |
    +--------------------+      |
    | Worker process 2   |-----/
    +--------------------+

As you can see, Worker process 1 and Worker process 2 have the same Memcached connection.

Suppose that users Joe and Jane visit your website at the same time. Joe’s request is handled by Worker process 1, and Jane’s request is handled by Worker process 2. Both worker processes want to fetch something from Memcached. Suppose that in order to do that, both handlers need to send a "FETCH" command to Memcached.

But suppose that, after worker process 1 having only sent "FE", a context switch occurs, and worker process 2 starts sending a "FETCH" command to Memcached as well. If worker process 2 succeeds in sending only one bye, F, then Memcached will receive a command which begins with "FEF", a command that it does not recognize. In other words: the data from both handlers get interleaved. And thus Memcached is forced to handle this as an error.

This problem can be solved by reestablishing the connection to Memcached after forking:

    +--------------------+
    | ApplicationSpawner |------+----[Memcached server]
    +--------------------+      |                   |
                                |                   |
    +--------------------+      |                   |
    | Worker process 1   |-----/|                   |
    +--------------------+      |                   |  <--- created this
                                X                   |       new
                                                    |       connection
                                X <-- closed this   |
    +--------------------+      |     old           |
    | Worker process 2   |-----/      connection    |
    +--------------------+                          |
              |                                     |
              +-------------------------------------+

Worker process 2 now has its own, separate communication channel with Memcached. The code in environment.rb looks like this:

    if defined?(PhusionPassenger)
        PhusionPassenger.on_event(:starting_worker_process) do |forked|
            if forked
                # We're in smart spawning mode.
                reestablish_connection_to_memcached
            else
                # We're in conservative spawning mode. We don't need to do anything.
            end
        end
    end

#### 11.3.2. Example 2: Log file sharing (not harmful)

There are also cases in which unintentional file descriptor sharing is not harmful. One such case is log file file descriptor sharing. Even if two processes write to the log file at the same time, the worst thing that can happen is that the data in the log file is interleaved.

To guarantee that the data written to the log file is never interleaved, you must synchronize write access via an inter-process synchronization mechanism, such as file locks. Reopening the log file, like you would have done in the Memcached example, doesn’t help.

### 11.4. Smart spawning gotcha #2: the need to revive threads

Another part of the fork() system call’s semantics is the fact that threads disappear after a fork call. So if you’ve created any threads in environment.rb, then those threads will no longer be running in newly created worker process. You need to revive them when a new worker process is created. Use the :starting_worker_process event that Phusion Passenger provides, like this:

    if defined?(PhusionPassenger)
        PhusionPassenger.on_event(:starting_worker_process) do |forked|
            if forked
                # We're in smart spawning mode.
                ... code to revive threads here ...
            else
                # We're in conservative spawning mode. We don't need to do anything.
            end
        end
    end

### 11.5. Smart spawning gotcha #3: code load order

This gotcha is only applicable to the smart spawn method, not the smart-lv2 spawn method.

If your application expects the Rails framework to be not loaded during the beginning of environment.rb, then it can cause problems when an ApplicationSpawner is created from a FrameworkSpawner, which already has the Rails framework loaded. The most common case is when applications try to patch Rails by dropping a modified file that has the same name as Rails’s own file, in a path that comes earlier in the Ruby search path.

For example, suppose that we have an application which has a patched version of active_record/base.rb located in RAILS_ROOT/lib/patches, and RAILS_ROOT/lib/patches comes first in the Ruby load path. When conservative spawning is used, the patched version of base.rb is properly loaded. When smart (not smart-lv2) spawning is used, the original base.rb is used because it was already loaded, so a subsequent require "active_record/base" has no effect.