Phusion Passenger users guide, Apache version

# Phusion Passenger users guide, Apache version

Phusion Passenger is an application server which can directly integrate into Apache. It is designed to be easy to use, fast, stable and reliable and is used by hundreds of thousands of websites all over the world.

Phusion Passenger is a so-called polyglot application server because it supports applications written in multiple programming languages. At this time, Ruby and Python are supported.

This users guide will teach you:

- How to install Phusion Passenger.

- How to configure Phusion Passenger.

- How to deploy Ruby and Python applications.

- How to solve common problems.

This guide assumes that the reader is somewhat familiar with Apache and with using the command line.

## 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. OpenBSD is supported since version 5.2. 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. Support on this forum is provided by the community on a best-effort basis, so a (timely) response is not guaranteed.

- Email support@phusion.nl if you are a Phusion Passenger Enterprise customer. Please mention your order reference. If you are not an Enterprise customer, we kindly redirect you to the community discussion forum instead.

- Commercial support contracts are also available.

- Report security vulnerabilities to support@phusion.nl. We will do our best to respond to you as quickly as we can, so please do not disclose the vulnerability until then.

Please consult the Phusion Passenger website for a full list of support resources.

## 2. Installation

### 2.1. Synopsis

The Phusion Passenger installation process consists of two steps:

1. The obtainment step, where you download the Phusion Passenger files puts them somewhere on your system. This can be done through downloading the source tarball, installing the Ruby gem or installing a native OS package via APT or YUM.

2. The integration step, where you configure Phusion Passenger so that it works properly with other system components such as Apache, Nginx, Ruby, Python, etc.

Because Phusion Passenger is designed to run in a wide variety of operating systems and configurations, both steps can be done in multiple ways. Most users — especially first-time users — will be satisfied with the generic installation instructions which covers both steps. However some users may prefer OS-specific installation instructions, which allow Phusion Passenger to better integrate into the operating system. Better integration is characterized by following OS-specific conventions.

If you are not familiar with system administration and do not understand all the choices, then we recommend you to go with the RubyGems generic installation method (if you’re a Ruby user) or the tarball generic installation method (if you’re not a Ruby user).

The steps for upgrading or downgrading Phusion Passenger is almost the same as the steps for installing. All the installation guides in this section will also teach you how to upgrade and downgrade.

### 2.2. Generic installation, upgrade and downgrade method: via RubyGems

RubyGems is only used as a method to obtain the Phusion Passenger files, so in case you have multiple Ruby versions it does not matter which Ruby’s RubyGems you use for installation. Once installed, Phusion Passenger can work with all other Ruby versions on your system.

#### Step 1: figuring out whether your Ruby is installed the home directory or system-wide

Ruby may either be installed in the home directory, or system-wide. If it’s installed system-wide then we will want to install gems system-wide as well, so you need to switch to a root prompt first. If Ruby is installed in the home directory then we will want to install gems to the home directory as well, as a normal user.

To find out which case applies, run the following command to find out where the ruby command is:

    which ruby

Do you see a filename that references /home or /Users? If so then your Ruby interpreter is installed in your home directory and you can proceed to step 2. Otherwise, you need to switch to a root prompt by running one of the following commands:

- Are you using RVM? Run rvmsudo -s

- Are you not using RVM, or do you not know what RVM is? Run sudo -s

- Is sudo not installed on your system? Run su -c bash

You must maintain this root prompt throughout this installation guide.

#### Step 2: install the gem

Open Source

Install the latest gem to obtain the files for the latest stable version of the open source Phusion Passenger:

    gem install passenger

Sometimes you will want to obtain the latest beta version of Phusion Passenger. Beta versions are not normally selected by gem install, so to opt-in for beta versions you have to add the --pre argument:

    gem install passenger --pre

If you want to obtain a specific version of Phusion Passenger, e.g. because you are downgrading, then specify the version number with --version:

    gem install passenger --version 3.0.0

If you want to obtain a specific beta version of Phusion Passenger then you must also pass --pre:

    gem install passenger --version 3.9.1.beta --pre

Enterprise

The gem install command only installs the open source version of Phusion Passenger. Phusion Passenger Enterprise customers should obtain the gem from the Customer Area instead. Login with your order reference and password. The Customer Area will show you a list of files.

First, download the license key and save it as /etc/passenger-enterprise-license.

Next, download the gem file for the version you want (passenger-enterprise-server-x.x.x.gem) and install it with:

    gem install passenger-enterprise-server-x.x.x.gem

#### Step 3: add the RubyGems bin directory to your $PATH

If you all of the following are applicable to you:

- You are on Debian or Ubuntu,

- and you installed RubyGems through APT,

- and your Ruby interpreter is installed system-wide,

…then you must ensure that the RubyGems bin directory is in your $PATH, which is the environment variable that dictates where your command prompt will look for commands. If any of the above conditions do not apply to you, then you can skip this step.

Open /etc/bash.bashrc or /etc/bashrc (whichever is available) and add the following to the end of the file. Also run this command in your terminal.

    export PATH=$PATH:/var/lib/gems/1.8/bin:/var/lib/gems/1.9/bin

#### Step 4: loosen permissions

If in step 1 you determined that your Ruby interpreter is installed in your home directory, then you need to make sure that the Phusion Passenger gem directory is accessible by your web server. To do that, you must ensure that the Phusion Passenger gem directory, as well as all parent directories, have the world-executable permission.

To find out where the Phusion Passenger gem directory is, run:

    passenger-config --root

Suppose that the above command outputs /home/phusion/.rvm/gems/ruby-1.9.3-p362/gems/passenger-x.x.x. Then you chmod o+x the directory itself and all parent directories up until /home/phusion:

    chmod o+x /home/phusion/.rvm/gems/ruby-1.9.3-p362/gems/passenger-x.x.x
    chmod o+x /home/phusion/.rvm/gems/ruby-1.9.3-p362/gems
    chmod o+x /home/phusion/.rvm/gems/ruby-1.9.3-p362
    chmod o+x /home/phusion/.rvm/gems
    chmod o+x /home/phusion/.rvm
    chmod o+x /home/phusion

#### Step 5: run the Phusion Passenger installer

The Phusion Passenger gem only contains source files. In this step we will use the installer to compile the Phusion Passenger binaries, which include the various Phusion Passenger agent executables and the Phusion Passenger Apache module.

Run the following command and follow the on-screen instructions.

    passenger-install-apache2-module

At the end of the installation process, you will be asked to copy and paste a configuration snippet (containing LoadModule, PassengerRoot, etc.) into your Apache configuration file. If you’re upgrading, then you already had a similar configuration snippet. Be sure to remove the old one before pasting the new one.

Different operating systems and Apache installations have different conventions with regard to where the Apache configuration file is and how it is organized. Please read Working with the Apache configuration file if you’re not familiar with it. That section is especially of interest for OS X Server >= 10.8 users because the configuration file may not be at a surprising location.

If compilation doesn’t succeed, then please consult the Troubleshooting section.

What does the installer do?

Despite the name, this "installer" doesn’t actually install anything. The installer checks whether all required dependencies are installed, invokes the compiler, and tells you how to modify the Apache configuration file. However, it doesn’t copy any files to outside the Phusion Passenger source directory.

passenger-install-apache2-module is actually just a user-friendly frontend around the command rake apache2, which performs the actual compilation of Phusion Passenger.

#### Step 6: Verifying that Phusion Passenger is running

Restart your web server and run:

    passenger-memory-stats

You should see the web server processes as well as a number of Phusion Passenger processes (e.g. PassengerWatchdog, PassengerHelperAgent). Congratulations, Phusion Passenger is now installed and running!

If the output is not as expected, then please refer to the Troubleshooting section.

### 2.3. Generic installation, upgrade and downgrade method: via tarball

#### Step 1: download and extract the tarball

Download the open source Phusion Passenger tarball from the Phusion Passenger website. Specific older versions are not found on the Phusion Passenger website, but are found in the following places:

- All versions starting from 4.0.0 can be found on Google Code.

- All versions prior to 4.0.0, except for beta releases and Release Candidates, can be found on RubyForge.

- All beta releases and Release Candidates prior to 4.0.0 beta 1 can be found on Google Code.

If you a Phusion Passenger Enterprise customer, download the Phusion Passenger Enterprise tarball from the Customer Area. Also be sure to download the license key and save it as /etc/passenger-enterprise-license.

Once you have downloaded the tarball, pick a location to extract it to. You can pick any location. A good location is /opt/passenger. Let’s call this location $PREFIX. Create this directory and extract the tarball as follows:

    mkdir $PREFIX
    cd $PREFIX
    tar xzvf /location-to/passenger-x.x.x.tar.gz
    cd $PREFIX/passenger-x.x.x

Note that passenger-x.x.x should be passenger-enterprise-server-x.x.x if you’re using Phusion Passenger Enterprise.

#### Step 2: loosen permissions

The Phusion Passenger directory must be accessible by the web server and by any web apps you want to run. To do that, you must ensure that the Phusion Passenger gem directory, as well as all parent directories, have the world-executable permission.

Suppose that the Phusion Passenger directory is /opt/passenger/passenger-4.0.0. Run chmod o+x on the directory itself and all parent directories.

    chmod o+x /opt/passenger/passenger-4.0.0
    chmod o+x /opt/passenger
    chmod o+x /opt

#### Step 3: installing Ruby and Rake

Phusion Passenger supports multiple languages and its core is written in C++, but its installer and administration tools are written in Ruby, so you must install that.

Even though Ruby is required, Ruby will not be loaded during normal operation unless you deploy a Ruby web application on Phusion Passenger.

Run ruby --version and rake --version to find out whether both commands are already installed and recent enough. Phusion Passenger requires Ruby >= 1.8.6. Any Rake version will do.

Debian 6

We recommend you to use the Brightbox Ruby packages. They provide more up-to-date versions of Ruby than Debian’s official repositories provide. Their Ubuntu Lucid repository is compatible with Debian 6. If you do not want to use the Brightbox repository, then follow the instructions for Debian 5.

Create /etc/apt/sources.list.d/brightbox-source.list:

    deb  http://ppa.launchpad.net/brightbox/ruby-ng/ubuntu  lucid main

Install the Brightbox APT public key:

    sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys C3173AA6

Then install Ruby and Rake:

    sudo apt-get update
    sudo apt-get install ruby1.9.3
    sudo gem install rake

Debian 5

Run:

    sudo apt-get update
    sudo apt-get install ruby rake

Then add the RubyGems bin directory to your $PATH.

Ubuntu

We recommend you to use the Brightbox Ruby packages. They provide more up-to-date versions of Ruby than Ubuntu’s official repositories provide.

    sudo apt-add-repository ppa:brightbox/passenger
    sudo apt-get update

If you’re on the older Ubuntu 8.04 Hardy release, the apt-add-repository command isn’t available so you have to install the repository and the key by hand:

    sudo sh -c 'echo "deb http://ppa.launchpad.net/brightbox/passenger/ubuntu hardy main" > /etc/apt/sources.list.d/brightbox-passenger.list'
    sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys C3173AA6
    sudo apt-get update

Other operating systems

Please install Ruby from the Ruby website. Once Ruby is installed, run the following command (possibly as root) to install Rake:

    gem install rake

#### Step 4: figuring out whether your Ruby is installed the home directory or system-wide

Depending on whether you installed Ruby system-wide, you need to enter a root prompt before continuing to step 5. Please refer to this section.

#### Step 5: run the Phusion Passenger installer

Please refer to this section. Note that the passenger-install-apache2-module command is inside the bin subdirectory of the Phusion Passenger source directory, so you would have to run something like /opt/passenger/passenger-x.x.x/bin/passenger-install-apache2-module.

#### Step 6: Verifying that Phusion Passenger is running

Please refer to this section. Note that all Phusion Passenger administration scripts are located inside the bin subdirectory of the Phusion Passenger source directory, so you would have to run something like /opt/passenger/passenger-x.x.x/bin/passenger-memory-stats.

### 2.4. Installing or upgrading on Debian 6 or Ubuntu

John Leach from Brightbox has kindly provided Ubuntu packages for Phusion Passenger. The Ubuntu Lucid packages are compatible with Debian 6. The packages are available from the Brightbox repository. Only packages for the open source version of Phusion Passenger are provided. Phusion Passenger Enterprise customers should use the generic RubyGems installation method or the generic tarball installation method instead.

If you use these packages to install Phusion Passenger then you do not need to run passenger-install-apache2-module or passenger-install-nginx-module. These packages contain all the binaries that you need.

Apache

On Ubuntu versions newer than 8.04 Hardy, register the Brightbox Apache PPA as follows:

    sudo apt-add-repository ppa:brightbox/passenger
    sudo apt-get update

On Ubuntu 8.04 Hardy and on Debian, the apt-add-repository command isn’t available so you have to install the repository and the key by hand.

Debian 6:

    sudo sh -c 'echo "deb http://ppa.launchpad.net/brightbox/passenger/ubuntu lucid main" > /etc/apt/sources.list.d/brightbox-passenger.list'
    sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys C3173AA6
    sudo apt-get update

Ubuntu 8.04 Hardy:

    sudo sh -c 'echo "deb http://ppa.launchpad.net/brightbox/passenger/ubuntu hardy main" > /etc/apt/sources.list.d/brightbox-passenger.list'
    sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys C3173AA6
    sudo apt-get update

You can proceed with installing Phusion Passenger by running:

    sudo apt-get install libapache2-mod-passenger

The Apache package provides configuration snippets for you, so you don’t need to modify any Apache configuration to get it to load Phusion Passenger.

Nginx

On Ubuntu versions newer than 8.04 Hardy, register the Brightbox Apache PPA as follows:

    sudo apt-add-repository ppa:brightbox/passenger-nginx
    sudo apt-get update

On Ubuntu 8.04 Hardy and on Debian, the apt-add-repository command isn’t available so you have to install the repository and the key by hand.

Debian 6:

    sudo sh -c 'echo "deb http://ppa.launchpad.net/brightbox/passenger-nginx/ubuntu lucid main" > /etc/apt/sources.list.d/brightbox-passenger-nginx.list'
    sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys C3173AA6
    sudo apt-get update

Ubuntu 8.04 Hardy:

    sudo sh -c 'echo "deb http://ppa.launchpad.net/brightbox/passenger/ubuntu hardy main" > /etc/apt/sources.list.d/brightbox-passenger-nginx.list'
    sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys C3173AA6
    sudo apt-get update

Then:

    sudo apt-get install nginx-full

You’ll then need to enable the Phusion Passenger module in Nginx by creating the following configuration file:

    sudo sh -c 'echo "passenger_root /usr/lib/phusion-passenger;" > /etc/nginx/conf.d/passenger.conf'

Then restart Nginx to apply the changes:

    sudo /etc/init.d/nginx restart

Standalone

Unfortunately, no packages are provided for Phusion Passenger Standalone.

### 2.5. Installing or upgrading on Red Hat, Fedora, CentOS or ScientificLinux

YUM repositories with RPMs are maintained by Erik Ogan and Stealthy Monkeys Consulting. Only packages for the open source version of Phusion Passenger are provided. Phusion Passenger Enterprise customers should use the generic RubyGems installation method or the generic tarball installation method instead.

If you use YUM to install Phusion Passenger then you do not need to run passenger-install-apache2-module or passenger-install-nginx-module. The YUM packages contain all the binaries that you need. You also don’t need to modify any Apache or Nginx configuration to get them to load Phusion Passenger, the packages provide configuration snippets for you as well.

#### Step 1: Import the Stealthy Monkeys Consulting’s GPG key

    rpm --import http://passenger.stealthymonkeys.com/RPM-GPG-KEY-stealthymonkeys.asc

#### Step 2: Install the release package

Install the passenger-release package from the main repository.

Fedora Core 17:

    yum install http://passenger.stealthymonkeys.com/fedora/17/passenger-release.noarch.rpm

Fedora Core 16:

    yum install http://passenger.stealthymonkeys.com/fedora/16/passenger-release.noarch.rpm

Fedora Core 15:

    yum install http://passenger.stealthymonkeys.com/fedora/15/passenger-release.noarch.rpm

Fedora Core 14:

    yum install http://passenger.stealthymonkeys.com/fedora/14/passenger-release.noarch.rpm

RHEL 6 / CentOS 6 / ScientificLinux 6: (Note: these packages depend on EPEL.)

    yum install http://passenger.stealthymonkeys.com/rhel/6/passenger-release.noarch.rpm

RHEL 5 / CentOS 5 / ScientificLinux 5: (Note: these packages depend on EPEL.)

    rpm -Uvh http://passenger.stealthymonkeys.com/rhel/5/passenger-release.noarch.rpm

#### Step 3: Install the right Phusion Passenger package

From there you can use YUM to install packages. For example, try one of these:

Phusion Passenger for Apache:

    yum install mod_passenger

Phusion Passenger for Nginx:

    yum install nginx-passenger

Phusion Passenger Standalone:

    yum install passenger-standalone

#### Building your own packages

There are instructions for building your own packages and Yum repositories in the rpm directory ReadMe within the GitHub repository.

### 2.6. Upgrading from open source to Enterprise

Phusion Passenger comes in two variants: an open source version, as well as an Enterprise version which introduces a myriad of useful features that can improve stability and performance and efficiency.

Customers who have bought Phusion Passenger Enterprise can upgrade their open source installation to Enterprise as follows:

1. Uninstall the open source Phusion Passenger.

2. Install the Enterprise version by following one of the installation guides in this section (e.g. RubyGems generic installation or tarball generic installation).

The uninstallation is necessary because the Enterprise Ruby gem has a different gem name (passenger-enterprise-server instead of passenger), but the same administration command names (e.g. passenger-status). Uninstalling the open source version avoids any conflicts.

### 2.7. Cryptographic verification of installation files

#### 2.7.1. Synopsis

We digitally sign various files with our GPG key so that you can check whether they’re legit, i.e. whether they really came from Phusion and haven’t been tampered with by a third party. We apply signing since the open source version 4.0.0 RC 4, or the Enterprise version 4.0.0 RC 1.

#### 2.7.2. Importing the Phusion Software Signing key

Phusion’s GPG key for signing software is as follows:

    Phusion Software Signing (software-signing@phusion.nl)
    Short key ID: 0x0A212A8C
    Long key ID: 0x2AC745A50A212A8C
    Fingerprint: D5F0 8514 2693 9232 F437  AB72 2AC7 45A5 0A21 2A8C

This key is stored at the Phusion website and at the key servers sks-keyservers.net and keyserver.ubuntu.com. You can import it to your keyring with one of these command:

    gpg --keyserver pool.sks-keyservers.net --search-keys 0x2AC745A50A212A8C
    # -OR-
    gpg --keyserver keyserver.ubuntu.com --search-keys 0x2AC745A50A212A8C

The Phusion Software Signing key is only used for signing software. It’s never used for signing emails or for encrypting files, so please be suspicious if you encounter usage of this key outside the context of signing software, and alert us at support@phusion.nl. Include "notspam" in the message to bypass our spam filter.

The email address software-signing@phusion.nl redirects to info@phusion.nl so it’s safe to send email there.

#### 2.7.3. Verifying the Phusion Software Signing key

The Phusion Software Signing key is also signed by the Phusion founders. Their keys are as follows:

    Hongli Lai (hongli@phusion.nl)
    Short key ID: 4B6F4332
    Long key ID: 06A131094B6F4332
    Fingerprint: 64E8 0420 FC6A 499F 9E1F  81FA 06A1 3109 4B6F 4332

    Ninh Bui (ninh@phusion.nl)
    Short key ID: 6FAF3782
    Long key ID: BA8DA3F46FAF3782
    Fingerprint: 353A 398C 49AF 5CD5 74A0  656C BA8D A3F4 6FAF 3782

Both keys are stored at both sks-servers.net and keyserver.ubuntu.com. Import them with:

    gpg --keyserver pool.sks-servers.net --search-keys 0x06A131094B6F4332
    gpg --keyserver pool.sks-servers.net --search-keys 0xBA8DA3F46FAF3782
    # -OR-
    gpg --keyserver keyserver.ubuntu.com --search-keys 0x06A131094B6F4332
    gpg --keyserver keyserver.ubuntu.com --search-keys 0xBA8DA3F46FAF3782

#### 2.7.4. Verifying the gem and tarball

You can find the open source version’s gem and tarball GPG signatures at https://www.phusionpassenger.com/signatures/. The Enterprise version’s GPG signatures can be found in the Customer Area. All signatures have the .asc extension. Once you have imported our key, you can verify the validity of a file against its signature as follows:

    $ gpg --verify passenger-x.x.x.tar.gz.asc passenger-x.x.x.tar.gz
    gpg: Signature made Mon Mar 11 09:45:46 2013 CET using RSA key ID 0A212A8C
    gpg: Good signature from "Phusion Software Signing <software-signing@phusion.nl>"

#### 2.7.5. Verifying Git signatures

Tags in the Git repository for the open source version are also tagged. You can verify a Git tag as follows:

    $ git tag --verify release-x.x.x
    object d886f34b5705e4314feccaf0d77b9a38416e15e0
    type commit
    tag release-4.0.0.rc5
    tagger Hongli Lai (Phusion) <hongli@phusion.nl> 1362993117 +0100

    This is a tag message.
    gpg: Signature made Mon Mar 11 10:12:02 2013 CET using RSA key ID 0A212A8C
    gpg: Good signature from "Phusion Software Signing <software-signing@phusion.nl>"

#### 2.7.6. Verifying DEB and RPM packages

The DEB and RPM packages are signed with the signatures of the respective packagers. Phusion does not provide signatures for them.

#### 2.7.7. Revocation

In the event our key is compromised, we will revoke the key and upload the revocation information to sks-servers.net and keyserver.ubuntu.com. However your system will not know about the revocation until you update the keys from the keyservers. You should update your keys regularly (e.g. once a week) by invoking:

    gpg --refresh-keys --keyserver pool.sks-servers.net
    # -OR-
    gpg --refresh-keys --keyserver keyserver.ubuntu.com

### 2.8. Non-interactive, automatic, headless installs or upgrades

By default, the installer (passenger-install-apache2-module) is interactive. If you want to automate installation then you can do so by passing --auto to the installer. See also passenger-install-apache2-module --help for more options.

### 2.9. Customizing the compilation process

#### 2.9.1. Setting the compiler

You can force the Phusion Passenger build system to use a specific C or C++ compiler by setting the CC and CXX environment variables. These may be set to any arbitrary shell commands.

For example, contributors who want to hack on Phusion Passenger may want to use Clang for faster compilation and ccache for faster recompilation, and may want to enable more error-catching compilation flags:

    export CC='ccache clang -fcolor-diagnostics -Qunused-arguments -fcatch-undefined-behavior -ftrapv'
    export CXX='ccache clang++ -fcolor-diagnostics -Qunused-arguments -fcatch-undefined-behavior -ftrapv'

#### 2.9.2. Adding additional compiler or linker flags

On some systems, C/C++ libraries and headers that Phusion Passenger requires may be located in a non-standard directory. You can force the Phusion Passenger build system to look in those locations by injecting compiler and linker flags using the following environment variables:

EXTRA_PRE_CFLAGS

  These flags are injected into all C compiler invocations that involve compiling C or C++ source files. This includes compiler invocations that compile and link. The flags are injected at the beginning of the command string, even before EXTRA_PRE_LDFLAGS.

EXTRA_CFLAGS

  Similar to EXTRA_PRE_CFLAGS, but injected at the end of the command string, before EXTRA_LDFLAGS.

EXTRA_PRE_CXXFLAGS

  Similar to EXTRA_PRE_CFLAGS, but for C++ compiler invocations.

EXTRA_CXXFLAGS

  Similar to EXTRA_CFLAGS, but for C++ compiler invocations.

EXTRA_PRE_LDFLAGS

  These flags are injected into all C/C++ compiler invocations that involve linking. This includes compiler invocations that compile and link. The flags are injected at the beginning of the command string, but after EXTRA_PRE_CFLAGS and EXTRA_PRE_CXXFLAGS.

EXTRA_LDFLAGS

  Similar to EXTRA_PRE_LDFLAGS, but injected at the very end of the command string, even after EXTRA_CFLAGS and EXTRA_CXXFLAGS.

#### 2.9.3. Forcing location of certain command line tools

The Phusion Passenger build system attempts to autodetect many things by locating relevant helper tools. For example, to find out which compiler flags it should use for compiling Apache modules, it locates the apxs2 command and queries it. To find out which compiler flags it should use for libcurl, it queries the curl-config command. These commands may not be in $PATH, or even when they are you may want to use a different one.

You can often force the build to find certain command line tools at certain locations by using the following environment variables:

HTTPD

  The location of the httpd executable (the Apache server executable).

APXS2

  The location of the apxs2 executable (the Apache module developer tool).

APR_CONFIG

  The location of the apr-config executable (the Apache Portable Runtime developer tool).

APU_CONFIG

  The location of the apu-config executable (the Apache Portable Runtime Utility developer tool).

MAKE

  The location of a make tool. It does not matter which implementation of make this is.

GMAKE

  The location of the GNU-compatible make tool.

### 2.10. Working with the Apache configuration file

On most systems the Apache configuration file is located in either /etc/apache2/httpd.conf or /etc/apache2/apache2.conf. However, to allow better organization, many operating systems and Apache distributions also read configuration files in the conf.d, mods-enabled and sites-enabled subdirectories.

mods-enabled contains symlinks to files in mods-available. This latter subdirectory contains config files for all available modules, while mods-enabled contains only a subset, namely the modules that should actually be enabled. The symlinks are created using the a2enmod tool. .load files contain LoadModule directives, while .conf files contain all other configuration directives.

Use mods-enabled/mods-available to store Phusion Passenger configuration if you can:

- Create /etc/apache2/mods-available/passenger.load and paste the LoadModule ... directive that passenger-install-apache2-module outputs.

- Create /etc/apache2/mods-available/passenger.conf and paste the PassengerRoot and other Phusion Passenger options.

- Enable by running sudo a2enmod passenger.

If the mods-enabled mechanism is not available then you can paste configuration snippets into httpd.conf or apache2.conf directly.

On OS X Server >= 10.8 Mountain Lion the location of the Apache configuration file depends on whether you use Web Services or not. If you do, then the configuration file is in /Library/Server/Web/Config/apache2/httpd_server_app.conf. If you do not, then the configuration file is in /etc/apache2/httpd.conf.

### 2.11. Disabling without uninstalling

You can temporarily unload (disable) Phusion Passenger from the web server, without uninstalling the Phusion Passenger files, so that the web server 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 through the hassle of uninstalling Phusion Passenger completely. When disabled, Phusion Passenger will not occupy any memory or CPU or otherwise interfere with the web server.

To unload Phusion Passenger from the web server, edit your Apache configuration file(s) and comment out:

- all Phusion Passenger configuration directives.

- the LoadModule passenger_module directive.

For example, if your configuration file looks like this…

    Listen *:80
    NameVirtualHosts *:80
    ....

    LoadModule passenger_module /somewhere/passenger-x.x.x/ext/apache2/mod_passenger.so

    PassengerRoot /somewhere/passenger/x.x.x
    PassengerDefaultRuby /usr/bin/ruby
    PassengerMaxPoolSize 10

    <VirtualHost *:80>
        ServerName www.foo.com
        DocumentRoot /webapps/foo/public
        RailsBaseURI /rails
    </VirtualHost>

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

    Listen *:80
    NameVirtualHosts *:80
    ....

    # LoadModule passenger_module /somewhere/passenger-x.x.x/ext/apache2/mod_passenger.so

    # PassengerRoot /somewhere/passenger/x.x.x
    # PassengerDefaultRuby /usr/bin/ruby
    # PassengerMaxPoolSize 10

    <VirtualHost *:80>
        ServerName www.foo.com
        DocumentRoot /webapps/foo/public
        # RailsBaseURI /rails
    </VirtualHost>

After you’ve done this, save the configuration file and restart the web server.

### 2.12. Uninstalling

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

- If you installed Phusion Passenger via a Ruby gem, then run gem uninstall passenger (or, if you’re an Phusion Passenger Enterprise user, gem uninstall passenger-enterprise-server). 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/passenger_root configuration directive.

- If you installed Phusion Passenger through APT or YUM, then use them to uninstall Phusion Passenger.

### 2.13. Moving to a different directory

If you installed Phusion Passenger through a tarball then you can move the Phusion Passenger directory to another location. This is not possible if you used any of the other installation methods.

First, move the directory to whereever you like:

    mv /opt/passenger/passenger-4.0.0 /usr/local/passenger-4.0.0

Next you must tell your web server that Phusion Passenger has moved. Open your Apache configuration file and set the PassengerRoot directive to the new location:

    PassengerRoot /usr/local/passenger-4.0.0

Restart your web server to finalize the change.

## 3. Deploying a Ruby on Rails 1.x or 2.x (but NOT Rails >= 3.x) 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 RailsEnv configuration option.

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

Add a virtual host entry to your Apache configuration file. Make sure that the following conditions are met:

- The virtual host’s document root must point to your Ruby on Rails application’s public folder.

- The Apache per-directory permissions must allow access to this folder.

- MultiViews must be disabled for this folder.

For example:

    <VirtualHost *:80>
        ServerName www.mycook.com
        DocumentRoot /webapps/mycook/public
        <Directory /webapps/mycook/public>
            Allow from all
            Options -MultiViews
        </Directory>
    </VirtualHost>

You may also need to tweak your file/folder permissions. Make sure that the following folders are readable and executable by Apache:

- this public folder.

- the application’s config folder.

- all parent folders. That is, /webapps/mycook and /webapps must also be readable and executable by Apache.

Then restart Apache. The application has now been deployed.

### 3.2. Deploying to a sub URI

Suppose that you already have a virtual host:

    <VirtualHost *:80>
        ServerName www.phusion.nl
        DocumentRoot /websites/phusion
        <Directory /websites/phusion>
            Allow from all
        </Directory>
    </VirtualHost>

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, add a RailsBaseURI option to the virtual host configuration, and also make sure that:

- The Apache per-directory permissions allow access to this folder.

- MultiViews is disabled for this folder.

For example:

    <VirtualHost *:80>
        ServerName www.phusion.nl
        DocumentRoot /websites/phusion
        <Directory /websites/phusion>
            Allow from all
        </Directory>

        RailsBaseURI /rails                   # <-- These lines have
        <Directory /websites/phusion/rails>   # <-- been added.
            Options -MultiViews               # <--
        </Directory>                          # <--
    </VirtualHost>

Then restart Apache. The application has now been deployed.

| If you’re deploying to a sub-URI then please make sure that your view templates correctly handles references to sub-URI static assets! Otherwise you may find broken links to images, CSS files, JavaScripts, etc. Please read How to fix broken images/CSS/JavaScript URIs in sub-URI deployments for more information.

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

    <VirtualHost *:80>
        ....
        RailsBaseURI /app1
        RailsBaseURI /app2
        RailsBaseURI /app3
    </VirtualHost>

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

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 RackEnv 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 Apache configuration file:

    <VirtualHost *:80>
        ServerName www.rackexample.com
        DocumentRoot /webapps/rack_example/public
        <Directory /webapps/rack_example/public>
            Allow from all
            Options -MultiViews
        </Directory>
    </VirtualHost>

And we’re done! After an Apache 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 virtual host entry to your Apache configuration file. Make sure that the following conditions are met:

- The virtual host’s document root must point to your Rack application’s public folder.

- The Apache per-directory permissions must allow access to this folder.

- MultiViews must be disabled for this folder.

For example:

    <VirtualHost *:80>
        ServerName www.rackapp.com
        DocumentRoot /webapps/rackapp/public
        <Directory /webapps/rackapp/public>
            Allow from all
            Options -MultiViews
        </Directory>
    </VirtualHost>

You may also need to tweak your file/folder permissions. Make sure that the following folders are readable and executable by Apache:

- this public folder.

- the application’s config folder.

- all parent folders. That is, /webapps/rackapp and /webapps must also be readable and executable by Apache.

Then restart Apache. The application has now been deployed.

### 4.3. Deploying to a sub URI

Suppose that you already have a virtual host:

    <VirtualHost *:80>
        ServerName www.phusion.nl
        DocumentRoot /websites/phusion
        <Directory /websites/phusion>
            Allow from all
        </Directory>
    </VirtualHost>

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, add a RackBaseURI option to the virtual host configuration, and also make sure that:

- The Apache per-directory permissions allow access to this folder.

- MultiViews is disabled for this folder.

For example:

    <VirtualHost *:80>
        ServerName www.phusion.nl
        DocumentRoot /websites/phusion
        <Directory /websites/phusion>
            Allow from all
        </Directory>

        RackBaseURI /rack                     # <-- These lines have
        <Directory /websites/phusion/rack>    # <-- been added.
            Options -MultiViews               # <--
        </Directory>                          # <--
    </VirtualHost>

Then restart Apache. The application has now been deployed.

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

    <VirtualHost *:80>
        ....
        RackBaseURI /app1
        RackBaseURI /app2
        RackBaseURI /app3
    </VirtualHost>

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

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'

    set :environment, ENV['RACK_ENV'].to_sym
    disable :run, :reload

    require 'app.rb'

    run Sinatra::Application

## 5. Deploying a WSGI (Python) application

Phusion Passenger supports all WSGI-compliant Python web applications. Suppose that you have a WSGI application in /webapps/wsgiapp. Then that folder must contain at least three entries:

- passenger_wsgi.py, which Phusion Passenger will use as the main entry point for your application. This file must export a WSGI object called 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/wsgiapp must, at minimum, look like this:

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

### 5.1. Tutorial/example: writing and deploying a Hello World WSGI application

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

    $ mkdir /webapps/wsgi_example
    $ mkdir /webapps/wsgi_example/public
    $ mkdir /webapps/wsgi_example/tmp

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

    $ cd /webapps/wsgi_example
    $ some_awesome_editor passenger_wsgi.py
    ...type in some source code...
    $ cat passenger_wsgi.py
    def application(environ, start_response):
      start_response('200 OK', [('Content-Type', 'text/plain')])
      return [b"hello world!\n"]

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

    <VirtualHost *:80>
        ServerName www.wsgiexample.com
        DocumentRoot /webapps/wsgi_example/public
        <Directory /webapps/wsgi_example/public>
            Allow from all
            Options -MultiViews
        </Directory>
    </VirtualHost>

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

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

Add a virtual host entry to your Apache configuration file. Make sure that the following conditions are met:

- The virtual host’s document root must point to your WSGI application’s public folder.

- The WSGI per-directory permissions must allow access to this folder.

- MultiViews must be disabled for this folder.

For example:

    <VirtualHost *:80>
        ServerName www.wsgiapp.com
        DocumentRoot /webapps/wsgiapp/public
        <Directory /webapps/wsgiapp/public>
            Allow from all
            Options -MultiViews
        </Directory>
    </VirtualHost>

You may also need to tweak your file/folder permissions. Make sure that the following folders are readable and executable by Apache:

- this public folder.

- the application’s config folder.

- all parent folders. That is, /webapps/wsgiapp and /webapps must also be readable and executable by Apache.

Then restart Apache. The application has now been deployed.

### 5.3. Redeploying (restarting the WSGI application)

Deploying a new version of a WSGI 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 Apache.

2. By creating or modifying the file tmp/restart.txt in the WSGI 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/wsgiapp/tmp/restart.txt

## 6. 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’s Apache module supports the following configuration options:

### 6.1. PassengerRoot <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 global server configuration.

### 6.2. PassengerDefaultRuby and PassengerRuby

Introduced in version 4.0.0.

This option specifies the default Ruby interpreter to use for web apps as well as for all sorts of internal Phusion Passenger helper scripts, e.g. the one used by PassengerPreStart. Please see PassengerRuby for more information, as well as how it relates to PassengerRuby.

This option may occur in the global server configuration. The default value is ruby, meaning that the Ruby interpreter will be looked up according to the PATH environment variable.

### 6.3. PassengerRuby <filename>

The PassengerDefaultRuby and PassengerRuby directives specify the Ruby interpreter to use. Similarly, the PassengerPython directive is for specifying the Python interpreter.

The relationship between PassengerDefaultRuby and PassengerRuby is as follows:

- PassengerDefaultRuby may only occur in the global server configuration.

- PassengerRuby may occur everywhere: in the global server configuration, in <VirtualHost>, in <Directory>, in <Location>, and in .htaccess if AllowOverride Options is on.

- You don’t have to specify PassengerRuby. In this case PassengerDefaultRuby is used as the Ruby interpreter. But if you do specify PassengerRuby then it will override PassengerDefaultRuby in that context. This allows you to use PassengerRuby to specify a different Ruby interpreter on a per-application basis.

Phusion Passenger not only uses Ruby to run web apps, but also for running certain helper tools that are written in Ruby, e.g. the internal helper script used by PassengerPreStart. These tools are always run using PassengerDefaultRuby, never by PassengerRuby. PassengerRuby is only used for running web apps.

The reason why PassengerDefaultRuby exists at all is because limitations in the Apache API prevents us from implementing the same behavior using only the PassengerRuby directive.

There is no PassengerDefaultPython because there are no Phusion Passenger tools written in Python. As such, having PassengerPython is enough.

The following example illustrates how it works and how you can use these options to specify different Ruby/Python interpreters for different web apps.

    # Use Ruby 1.8.7 by default.
    PassengerDefaultRuby /usr/bin/ruby1.8
    # Use Python 2.6 by default.
    PassengerPython /usr/bin/python2.6

    <VirtualHost *:80>
        # This Rails web app will use Ruby 1.8.7
        ServerName www.foo.com
        DocumentRoot /webapps/foo/public
    </VirtualHost>

    <VirtualHost *:80>
        # This Rails web app will use Ruby 1.9.3, as installed by RVM
        PassengerRuby /usr/local/rvm/wrappers/ruby-1.9.3/ruby
        ServerName www.bar.com
        DocumentRoot /webapps/bar/public

        # If you have a web app deployed in a sub-URI, customize
        # PassengerRuby/PassengerPython inside a <Location> block.
        # The web app under www.bar.com/blog will use JRuby 1.7.1
        RackBaseURI /blog
        <Location /blog>
            PassengerRuby /usr/local/rvm/wrappers/jruby-1.7.1/ruby
        </Location>
    </VirtualHost>

    <VirtualHost *:80>
        # This Flask web app will use Python 3.0
        PassengerPython /usr/bin/python3.0
        ServerName www.baz.com
        DocumentRoot /webapps/baz/public
    </VirtualHost>

RVM helper tool

Phusion Passenger provides the passenger-config --ruby-command tool for figuring out the correct command for invoking a specific Ruby interpreter. This is especially useful for RVM users. Suppose that you have both Ruby 1.8.7 and Ruby 1.9.3 installed through RVM, and you want to know the correct commands for each Ruby interpreter.

For this purpose we’ll want to invoke passenger-config using its full path, because each time you rvm use a different Ruby interpreter, RVM changes $PATH. If you did not install Phusion Passenger through the generic tarball installation method, then here’s how you can figure out where passenger-config is:

    $ which passenger-config
    /opt/passenger/bin/passenger-config

Now, switch to all the RVM Ruby interpreters you want to use. In each interpreter, invoke passenger-config --ruby-command. For Ruby 1.8.7:

    $ rvm use 1.8.7
    $ /opt/passenger/bin/passenger-config --ruby-command
    passenger-config was invoked through the following Ruby interpreter:
      Command: /usr/local/rvm/wrappers/ruby-1.8.7-p358/ruby
      Version: ruby 1.8.7 (2012-02-08 patchlevel 358) [universal-darwin12.0]
      To use in Apache: PassengerRuby /usr/local/rvm/wrappers/ruby-1.8.7-p358/ruby
      To use in Nginx : passenger_ruby /usr/local/rvm/wrappers/ruby-1.8.7-p358/ruby
      To use with Standalone: /usr/local/rvm/wrappers/ruby-1.8.7-p358/ruby /opt/passenger/bin/passenger start

    The following Ruby interpreter was found first in $PATH:
      Command: /usr/local/rvm/wrappers/ruby-1.8.7-p358/ruby
      Version: ruby 1.8.7 (2012-02-08 patchlevel 358) [universal-darwin12.0]
      To use in Apache: PassengerRuby /usr/local/rvm/wrappers/ruby-1.8.7-p358/ruby
      To use in Nginx : passenger_ruby /usr/local/rvm/wrappers/ruby-1.8.7-p358/ruby
      To use with Standalone: /usr/local/rvm/wrappers/ruby-1.8.7-p358/ruby /opt/passenger/bin/passenger start

    ## Notes for RVM users
    Do you want to know which command to use for a different Ruby interpreter? 'rvm use' that Ruby interpreter, then re-run 'passenger-config --ruby-command'.

Then, for Ruby 1.9.3:

    $ rvm use 1.9.3
    $ /opt/passenger/bin/passenger-config --ruby-command
    passenger-config was invoked through the following Ruby interpreter:
      Command: /usr/local/rvm/wrappers/ruby-1.9.3-p392/ruby
      Version: ruby 1.9.3p392 (2013-02-22 revision 39386) [x86_64-darwin12.2.1]
      To use in Apache: PassengerRuby /usr/local/rvm/wrappers/ruby-1.9.3-p392/ruby
      To use in Nginx : passenger_ruby /usr/local/rvm/wrappers/ruby-1.9.3-p392/ruby
      To use with Standalone: /usr/local/rvm/wrappers/ruby-1.9.3-p392/ruby /opt/passenger/bin/passenger start

    The following Ruby interpreter was found first in $PATH:
      Command: /usr/local/rvm/wrappers/ruby-1.9.3-p392/ruby
      Version: ruby 1.9.3p392 (2013-02-22 revision 39386) [x86_64-darwin12.2.1]
      To use in Apache: PassengerRuby /usr/local/rvm/wrappers/ruby-1.9.3-p392/ruby
      To use in Nginx : passenger_ruby /usr/local/rvm/wrappers/ruby-1.9.3-p392/ruby
      To use with Standalone: /usr/local/rvm/wrappers/ruby-1.9.3-p392/ruby /opt/passenger/bin/passenger start

    ## Notes for RVM users
    Do you want to know which command to use for a different Ruby interpreter? 'rvm use' that Ruby interpreter, then re-run 'passenger-config --ruby-command'.

### 6.4. PassengerPython <filename>

Introduced in version 4.0.0.

This option allows one to specify the Python interpreter to use. See PassengerRuby for more information. The default value is python, meaning that the Python interpreter will be looked up according to the PATH environment variable.

### 6.5. PassengerAppRoot <path/to/root>

By default, Phusion Passenger assumes that the application’s root directory is the parent directory of the public directory. This option allows one to specify the application’s root independently from the DocumentRoot, which is useful if the public directory lives in a non-standard place.

This option may occur in the following places:

- In the global server configuration.

- In a virtual host configuration block.

- In a <Directory> or <Location> block.

- In .htaccess, if AllowOverride Options is on.

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

Example:

    <VirtualHost test.host>
        DocumentRoot /var/rails/zena/sites/example.com/public
        PassengerAppRoot /var/rails/zena   # <-- normally Phusion Passenger would
                                           #     have assumed that the application
                                           #     root is "/var/rails/zena/sites/example.com"
    </VirtualHost>

### 6.6. PassengerSpawnMethod <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 PassengerSpawnMethod 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

  This spawning method caches code using the app preloader. Framework code is not cached between multiple applications, although it is cached within instances of the same application. Please read Spawning methods explained for a more detailed explanation of what smart spawning exactly does.

  Pros: Smart spawning caches code where possible to speed up the respawn process and is compatible with most applications

  Cons: It is possible that it may be incompatible with some applications

direct

  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 direct spawning exactly does.

  Pros: Direct 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. Direct spawning will also render Ruby Enterprise Edition’s memory reduction technology useless.

As of Passenger 3.2, conservative spawning was renamed to direct and smart-lv2 was renamed to smart. The old smart spawning has been removed in favor of the new version.

This option may occur in the following places:

- In the global server configuration.

- In a virtual host configuration block.

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

### 6.7. PassengerEnabled <on|off>

You can set this option to off to completely disable Phusion Passenger for a certain location. This is useful if, for example, you want to integrate a PHP application into the same virtual host as a Rails application.

Suppose that you have a Rails application in /apps/foo. Suppose that you’ve dropped Wordpress — a blogging application written in PHP — in /apps/foo/public/wordpress. You can then configure Phusion Passenger as follows:

    <VirtualHost *:80>
        ServerName www.foo.com
        DocumentRoot /apps/foo/public
        <Directory /apps/foo/public/wordpress>
            PassengerEnabled off
            AllowOverride all      # <-- Makes Wordpress's .htaccess file work.
        </Directory>
    </VirtualHost>

This way, Phusion Passenger will not interfere with Wordpress.

PassengerEnabled may occur in the following places:

- In the global server configuration.

- In a virtual host configuration block.

- In a <Directory> or <Location> block.

- In .htaccess.

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

### 6.8. PassengerTempDir <directory>

Specifies the directory that Phusion Passenger should use for storing temporary files. This includes things such as Unix socket files, buffered file uploads (see also PassengerUploadBufferDir), etc.

This option may be specified once, in the global server configuration. The default temp directory that Phusion Passenger uses is /tmp.

This option is especially useful if Apache is not allowed to write to /tmp (which is the case on some systems with strict SELinux policies) or if the partition that /tmp lives on doesn’t have enough disk space.

Command line tools

Some Phusion Passenger command line administration tools, such as passenger-status, must know what Phusion Passenger’s temp directory is in order to function properly. You can pass the directory through the PASSENGER_TMPDIR environment variable, or the TMPDIR environment variable (the former will be used if both are specified).

For example, if you set PassengerTempDir to /my_temp_dir, then invoke passenger-status after you’ve set the PASSENGER_TMPDIR or TMPDIR environment variable, like this:

    export PASSENGER_TMPDIR=/my_temp-dir
    sudo -E passenger-status
    # The -E option tells 'sudo' to preserve environment variables.

### 6.9. PassengerUploadBufferDir <directory>

Phusion Passenger buffers large file uploads to disk in order prevent slow file uploads from blocking web applications. By default, a subdirectory in the system’s temporary files directory (or a subdirectory in the directory specified in PassengerTempDir, if set) is automatically created for storing these buffered file uploads.

This configuration directive allows you to specify a different directory for storing buffered file uploads. If you’ve specified such a directory (as opposed to using Phusion Passenger’s default) then you must ensure that this directory exists.

This configuration directive is also useful if you’re using apache2-mpm-itk. The buffered file upload directory that Phusion Passenger creates by default has very strict permissions: it can only be accessed by the Apache worker processes. However, Phusion Passenger assumes that all Apache worker processes are running as the same user. apache2-mpm-itk breaks this assumption by running multiple Apache worker processes as different users. So if you’re using apace2-mpm-itk, you should set this option to a directory that is writable by all Apache worker processes, such as /tmp.

You may specify PassengerUploadBufferDir in the following places:

- In the global server configuration.

- In a virtual host configuration block.

- In a <Directory> or <Location> block.

- In .htaccess, if AllowOverrides Options is enabled.

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

### 6.10. PassengerRestartDir <directory>

As described in the deployment chapters of this document, Phusion Passenger checks the file tmp/restart.txt in the applications' root directory for restarting applications. Sometimes it may be desirable for Phusion Passenger to look in a different directory instead, for example for security reasons (see below). This option allows you to customize the directory in which restart.txt is searched for.

You may specify PassengerRestartDir in the following places:

- In the global server configuration.

- In a virtual host configuration block.

- In a <Directory> or <Location> block.

- In .htaccess, if AllowOverrides Options is enabled.

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

You can either set it to an absolute directory, or to a directory relative to the application root. Examples:

    <VirtualHost *:80>
        ServerName www.foo.com
        # Phusion Passenger will check for /apps/foo/public/tmp/restart.txt
        DocumentRoot /apps/foo/public
    </VirtualHost>

    <VirtualHost *:80>
        ServerName www.bar.com
        DocumentRoot /apps/bar/public
        # An absolute filename is given; Phusion Passenger will
        # check for /restart_files/bar/restart.txt
        PassengerRestartDir /restart_files/bar
    </VirtualHost>

    <VirtualHost *:80>
        ServerName www.baz.com
        DocumentRoot /apps/baz/public
        # A relative filename is given; Phusion Passenger will
        # check for /apps/baz/restart_files/restart.txt
        #
        # Note that this directory is relative to the APPLICATION ROOT, *not*
        # the value of DocumentRoot!
        PassengerRestartDir restart_files
    </VirtualHost>

What are the security reasons for wanting to customize PassengerRestartDir?

Touching restart.txt will cause Phusion Passenger to restart the application. So anybody who can touch restart.txt can effectively cause a Denial-of-Service attack by touching restart.txt over and over. If your web server or one of your web applications has the permission to touch restart.txt, and one of them has a security flaw which allows an attacker to touch restart.txt, then that will allow the attacker to cause a Denial-of-Service.

You can prevent this from happening by pointing PassengerRestartDir to a directory that’s readable by Apache, but only writable by administrators.

### 6.11. PassengerBufferResponse <on|off>

When turned on, application-generated responses are buffered by Apache. Buffering will happen in memory.

Before we proceed with explaining this configuration option, we want to state the following to avoid confusion. If you use Phusion Passenger for Apache, there are in fact two response buffering systems active:

1. The Apache response buffering system. PassengerBufferResponse turns this on or off.

2. The Phusion Passenger response buffering system, a.k.a. real-time disk-backed response buffering. This buffering system is always on, regardless of the value of PassengerBufferResponse.

Response buffering is useful because it protects against slow HTTP clients that do not read responses immediately or quickly enough. Buffering prevents such slow clients from blocking web applications that have limited concurrency. Because Phusion Passenger’s response buffering is always turned on, you are always protected. Therefore, PassengerBufferResponse is off by default, and you never should have to turn it on.

If for whatever reason you want to turn Apache-level response buffering on, you can do so with this option.

Apache’s response buffering works differently from Phusion Passenger’s. Apache’s buffering system buffers the entire response before attempting to send it to the client, while Phusion Passenger’s attempts to send the data to the client immediately. Therefore, if you turn on PassengerBufferResponse, you may interfere with applications that want to stream responses to the client. Apache’s version also buffers to memory only, making it problematic for large responses. Phusion Passenger’s version buffers to disk when the response exceeds a certain threshold.

How does response buffering - whether it’s done by Apache or by Phusion Passenger - exactly protect against slow clients? Consider an HTTP client that’s on a dial-up modem link, and your application process generates a 2 MB response. If the response is buffered 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 buffering responses, Phusion Passenger or Apache will read the application response as quickly as possible and will take care of forwarding the data to slow clients.

So keep in mind that enabling passenger_buffering_response 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 PassengerBufferResponse is turned on, Apache 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 PassengerBufferResponse 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 global server configuration.

- In a virtual host configuration block.

- In a <Directory> or <Location> block.

- In .htaccess.

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

| The PassengerBufferResponse directive should be turned off if responses can be huge. Because entire responses are buffered in memory when turned on.

### 6.12. PassengerRollingRestarts <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 global server configuration.

- In a virtual host configuration block.

- In a <Directory> or <Location> block.

- In .htaccess, if AllowOverride Options is on.

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

### 6.13. PassengerResistDeploymentErrors <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 global server configuration.

- In a virtual host configuration block.

- In a <Directory> or <Location> block.

- In .htaccess, if AllowOverride Options is on.

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

### 6.14. Security options

#### 6.14.1. PassengerUserSwitching <on|off>

Whether to enable user switching support.

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

#### 6.14.2. PassengerUser <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 global server configuration.

- In a virtual host configuration block.

- In a <Directory> or <Location> block.

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

#### 6.14.3. PassengerGroup <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 global server configuration.

- In a virtual host configuration block.

- In a <Directory> or <Location> block.

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

#### 6.14.4. PassengerDefaultUser <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 global server configuration. The default value is nobody.

#### 6.14.5. PassengerDefaultGroup <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 global server configuration. The default value is the primary group of the user specifified by PassengerDefaultUser.

#### 6.14.6. PassengerFriendlyErrorPages <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 global server configuration.

- In a virtual host configuration block.

- In a <Directory> or <Location> block.

- In .htaccess, if AllowOverride Options is on.

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

### 6.15. Resource control and optimization options

#### 6.15.1. PassengerMaxPoolSize <integer>

The maximum number of application processes that may simultaneously exist. A larger number results in higher memory usage, but improves the ability to handle concurrent HTTP requests.

The optimal value depends on your system’s hardware and your workload. You can learn more at the Phusion article Tuning Phusion Passenger’s concurrency settings.

If you find that your server is running out of memory then you should lower this value.

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

#### 6.15.2. PassengerMinInstances <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 Apache 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 PassengerPoolIdleTime).

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

For example, suppose that you have the following configuration:

    PassengerMaxPoolSize 15
    PassengerPoolIdleTime 10

    <VirtualHost *:80>
        ServerName foobar.com
        DocumentRoot /webapps/foobar/public
        PassengerMinInstances 3
    </VirtualHost>

When you start Apache, 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 PassengerMinInstances option may occur in the following places:

- In the global server configuration.

- In a virtual host configuration block.

- In a <Directory> or <Location> block.

- In .htaccess, if AllowOverride Limits is on.

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

#### 6.15.3. PassengerMaxInstances <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 PassengerMaxPoolSize. 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 PassengerMaxPoolSize will be enforced.

This option may occur in the following places:

- In the global server configuration.

- In a virtual host configuration block.

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 PassengerMaxPoolSize to 10. The e-commerce website is more important to you. You can then set PassengerMaxInstances 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.

#### 6.15.4. PassengerMaxInstancesPerApp <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 PassengerMaxPoolSize. 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 PassengerMaxPoolSize will be enforced.

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

Practical usage example

Suppose that you’re hosting two blogs (blog A and B) on your server, and that you’ve set PassengerMaxPoolSize to 10. Under normal circumstances, if blog A suddenly gets a lot of traffic, then A will use all 10 pool slots. If blog B suddenly gets some traffic, then it will only be able to use 1 pool slot (forcefully releasing 1 slot from A) until A’s traffic has settled down and it has released more pool slots.

If you consider both blogs equally important, then you can set PassengerMaxInstancesPerApp to 5. This way, both blogs will never use more than 5 pool slots.

Relation with PassengerMaxInstances

Unlike PassengerMaxInstances, this configuration option is global and applies to all applications. PassengerMaxInstances on the other hand is per-virtual host.

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

In summary, PassengerMaxInstancesPerApp divides the pool equally among the different web applications, while PassengerMaxInstances allows one to divide the pool unequally, according to each web application’s relative importance.

#### 6.15.5. PassengerPoolIdleTime <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 application 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 global server configuration. The default value is 300.

#### 6.15.6. PassengerMaxPreloaderIdleTime <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 global server configuration.

- In a virtual host configuration block.

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

#### 6.15.7. PassengerConcurrencyModel <process|thread>

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

Specifies the I/O concurrency model that should be used for application processes. Phusion Passenger supports two concurrency models:

- process - single-threaded, multi-processed I/O concurrency. Each application process only has a single thread and can only handle 1 request at a time. This is the concurrency model that Ruby applications traditionally used. It has excellent compatiblity (can work with applications that are not designed to be thread-safe) but is unsuitable workloads in which the application has to wait for a lot of external I/O (e.g. HTTP API calls), and uses more memory because each process has a large memory overhead.

- thread - multi-threaded, multi-processed I/O concurrency. Each application process has multiple threads (customizable via PassengerThreadCount). This model provides much better I/O concurrency and uses less memory because threads share memory with each other within the same process. However, using this model may cause compatibility problems if the application is not designed to be thread-safe.

This option may occur in the following places:

- In the global server configuration.

- In a virtual host configuration block.

- In a <Directory> or <Location> block.

- In .htaccess.

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

#### 6.15.8. PassengerThreadCount <number>

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

Specifies the number of threads that Phusion Passenger should spawn per application process. This option only has effect if PassengerConcurrencyModel is thread.

This option may occur in the following places:

- In the global server configuration.

- In a virtual host configuration block.

- In a <Directory> or <Location> block.

- In .htaccess.

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

#### 6.15.9. PassengerMaxRequests <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 global server configuration.

- In a virtual host configuration block.

- In a <Directory> or <Location> block.

- In .htaccess, if AllowOverride Limits is on.

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

| The PassengerMaxRequests 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.

#### 6.15.10. PassengerMaxRequestTime <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 global server configuration.

- In a virtual host configuration block.

- In a <Directory> or <Location> block.

- In .htaccess, if AllowOverride Limits is on.

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:

    <VirtualHost *:80>
        ServerName www.example.com
        DocumentRoot /webapps/my_app/public

        PassengerMaxRequestTime 2
        <Location /expensive_computation>
            PassengerMaxRequestTime 10
        </Location>
    </VirtualHost>

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

#### 6.15.11. PassengerMemoryLimit <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 global server configuration.

- In a virtual host configuration block.

- In a <Directory> or <Location> block.

- In .htaccess, if AllowOverride Limits is on.

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

| A word about permissions The PassengerMemoryLimit directive uses ps command to query memory usage information. On Linux, it further queries /proc to obtain additional memory usage information that’s not obtainable through ps. You should ensure that the ps works correctly and that the /proc filesystem is accessible by the PassengerHelperAgent process.

| The PassengerMaxRequests and PassengerMemoryLimit 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.

#### 6.15.12. PassengerStatThrottleRate <integer>

By default, Phusion Passenger performs several filesystem checks (or, in programmers jargon, stat() calls) each time a request is processed:

- It checks whether config/environment.rb, config.ru or passenger_wsgi.py is present, in order to autodetect Rails, Rack and WSGI applications.

- It checks whether restart.txt has changed or whether always_restart.txt exists, in order to determine whether the application should be restarted.

On some systems where disk I/O is expensive, e.g. systems where the harddisk is already being heavily loaded, or systems where applications are stored on NFS shares, these filesystem checks can incur a lot of overhead.

You can decrease or almost entirely eliminate this overhead by setting PassengerStatThrottleRate. Setting this option to a value of x means that the above list of filesystem checks will be performed at most once every x seconds. Setting it to a value of 0 means that no throttling will take place, or in other words, that the above list of filesystem checks will be performed on every request.

This option may occur in the following places:

- In the global server configuration.

- In a virtual host configuration block.

- In a <Directory> or <Location> block.

- In .htaccess, if AllowOverride Limits is on.

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

#### 6.15.13. PassengerPreStart <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 Apache 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 ServerName directive of the VirtualHost 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 PassengerMinInstances because application processes started with PassengerPreStart are subject to the usual idle timeout rules. See the example below for an explanation.

This option may occur in the following places:

- In the global server configuration.

- In a virtual host configuration block.

In each place, it may be specified any number of times.

##### Example 1: basic usage

Suppose that you have the following web applications.

    <VirtualHost *:80>
       ServerName foo.com
       DocumentRoot /webapps/foo/public
    </VirtualHost>

    <VirtualHost *:3500>
       ServerName bar.com
       DocumentRoot /webapps/bar/public
    </VirtualHost>

You want both of them to be pre-started during Apache 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 PassengerPreStart directives, like this:

    <VirtualHost *:80>
       ServerName foo.com
       DocumentRoot /webapps/foo/public
    </VirtualHost>

    <VirtualHost *:3500>
       ServerName bar.com
       DocumentRoot /webapps/bar/public
    </VirtualHost>

    PassengerPreStart http://foo.com/           # <--- added
    PassengerPreStart 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:

    <VirtualHost *:80>
       ServerName myblog.com
       DocumentRoot /webapps/wordpress
       RailsBaseURI /store
    </VirtualHost>

Then specify the domain name of its containing virtual host followed by the sub-URI, like this:

    <VirtualHost *:80>
       ServerName myblog.com
       DocumentRoot /webapps/wordpress
       RailsBaseURI /store
    </VirtualHost>

    PassengerPreStart 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:

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

##### Example 3: combining with PassengerMinInstances

Application processes started with PassengerPreStart are also subject to the idle timeout rules as specified by PassengerPoolIdleTime! 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 PassengerPreStart with PassengerMinInstances, like this:

    <VirtualHost *:80>
       ServerName foo.com
       DocumentRoot /webapps/foo/public
       # Added!
       PassengerMinInstances 1
    </VirtualHost>

    <VirtualHost *:3500>
       ServerName bar.com
       DocumentRoot /webapps/bar/public
       # Added!
       PassengerMinInstances 1
    </VirtualHost>

    PassengerPreStart http://foo.com/
    PassengerPreStart 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 Apache 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 Apache configuration file(s). In other words, it’s hard for Phusion Passenger to know which web applications are deployed on Apache until a web application is first accessed, and without such a list Phusion Passenger wouldn’t know which web applications to pre-start. It’s probably not completely impossible to obtain such a list, but this brings us to the following point;

- Users expect things like mod_env to work even in combination with Phusion Passenger. For example some people put “SetEnv PATH=….” in their virtual host block and they expect the web application to pick that environment variable up when it’s started. Information like this is stored in module-specific locations that Phusion Passenger cannot access directly. Even if the previous bullet point is solved and we can obtain a list of web applications, we cannot start the application with the correct mod_env information. mod_env is just one such example; there are probably many other Apache modules, all of which people expect to work, but we cannot answer to those expectations if PassengerPreStart is implemented as a simple on/off flag.

So as a compromise, we made it accept a URL. This is easier to implement for us and altough it looks weird, it behaves consistently w.r.t. cooperation with other Apache modules.

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

During Apache 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 Apache config file?

Put the web application’s virtual host’s ServerName value and the virtual host’s port in the URL, and put PassengerPreStart 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 PassengerPreStart support https:// URLs?

Yes. And it does not perform any certificate validation.

#### 6.15.14. PassengerHighPerformance <on|off>

By default, Phusion Passenger is compatible with mod_rewrite and most other Apache modules. However, a lot of effort is required in order to be compatible. If you turn PassengerHighPerformance to on, then Phusion Passenger will be a little faster, in return for reduced compatibility with other Apache modules.

In places where PassengerHighPerformance is turned on, mod_rewrite rules will likely not work. mod_autoindex (the module which displays a directory index) will also not work. Other Apache modules may or may not work, depending on what they exactly do. We recommend you to find out how other modules behave in high performance mode via testing.

This option is not an all-or-nothing global option: you can enable high performance mode for certain virtual hosts or certain URLs only. The PassengerHighPerformance option may occur in the following places:

- In the global server configuration.

- In a virtual host configuration block.

- In a <Directory> or <Location> block.

- In .htaccess.

In each place, it may be specified at most once. The default value is off, so high performance mode is disabled by default, and you have to explicitly enable it.

When to enable high performance mode?

If you do not use mod_rewrite or other Apache modules then it might make sense to enable high performance mode.

It’s likely that some of your applications depend on mod_rewrite or other Apache modules, while some do not. In that case you can enable high performance for only those applications that don’t use other Apache modules. For example:

    <VirtualHost *:80>
        ServerName www.foo.com
        DocumentRoot /apps/foo/public
        .... mod_rewrite rules or options for other Apache modules here ...
    </VirtualHost>

    <VirtualHost *:80>
        ServerName www.bar.com
        DocumentRoot /apps/bar/public
        PassengerHighPerformance on
    </VirtualHost>

In the above example, high performance mode is only enabled for www.bar.com. It is disabled for everything else.

If your application generally depends on mod_rewrite or other Apache modules, but a certain URL that’s accessed often doesn’t depend on those other modules, then you can enable high performance mode for a certain URL only. For example:

    <VirtualHost *:80>
        ServerName www.foo.com
        DocumentRoot /apps/foo/public
        .... mod_rewrite rules or options for other Apache modules here ...

        <Location /chatroom/ajax_update_poll>
            PassengerHighPerformance on
        </Location>
    </VirtualHost>

This enables high performance mode for http://www.foo.com/chatroom/ajax_update_poll only.

### 6.16. Compatibility options

#### 6.16.1. PassengerResolveSymlinksInDocumentRoot <on|off>

Configures whether Phusion Passenger should resolve symlinks in the document root. Please refer to How Phusion Passenger detects whether a virtual host is a web application for more information.

This option may occur in the following places:

- In the global server configuration.

- In a virtual host configuration block.

- In a <Directory> or <Location> block.

- In .htaccess, if AllowOverride Options is on.

In each place, it may be specified at most once. It is off by default.

#### 6.16.2. PassengerAllowEncodedSlashes <on|off>

By default, Apache doesn’t support URLs with encoded slashes (%2f), e.g. URLs like this: /users/fujikura%2fyuu. If you access such an URL then Apache will return a 404 Not Found error. This can be solved by turning on PassengerAllowEncodedSlashes as well as Apache’s AllowEncodedSlashes.

Is it important that you turn on both AllowEncodedSlashes and PassengerAllowEncodedSlashes, otherwise this feature will not work properly.

PassengerAllowEncodedSlashes may occur in the following places:

- In the global server configuration.

- In a virtual host configuration block.

- In a <Directory> or <Location> block.

- In .htaccess, if AllowOverride Options is on.

In each place, it may be specified at most once. It is off by default.

Please note however that turning on support for encoded slashes will break support for mod_rewrite passthrough rules. Because of bugs/limitations in Apache, Phusion Passenger can support either encoded slashes or mod_rewrite passthrough rules, but not both at the same time. Luckily this option can be specified anywhere, so you can enable it only for virtual hosts or URLs that need it:

    <VirtualHost *:80>
        ServerName www.example.com
        DocumentRoot /webapps/example/public
        AllowEncodedSlashes on
        RewriteEngine on

        # Check for maintenance file and redirect all requests
        RewriteCond %{DOCUMENT_ROOT}/system/maintenance.html -f
        RewriteCond %{SCRIPT_FILENAME} !maintenance.html
        RewriteRule ^.*$ /system/maintenance.html [L]

        # Make /about an alias for /info/about.
        RewriteRule ^/about$ /info/about [PT,L]

        <Location ~ "^/users/">
            # In a location block so that it doesn't interfere with the
            # above /about mod_rewrite rule.
            PassengerAllowEncodedSlashes on
        </Location>
    </VirtualHost>

With this, http://www.example.com/users/fujikura%2fyuu will work properly, and accessing http://www.example.com/about will properly display the result of http://www.example.com/info/about. Notice that PassengerAllowEncodedSlashes only interferes with passthrough rules, not with any other mod_rewrite rules. The rules for displaying maintenance.html will work fine even for URLs starting with "/users".

### 6.17. Logging and debugging options

#### 6.17.1. PassengerLogLevel <integer>

This option allows one to specify how much information Phusion Passenger should write to the Apache 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 global server configuration. The default is 0.

#### 6.17.2. PassengerDebugLogFile <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 global server configuration.

#### 6.17.3. PassengerDebugger <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 global server configuration.

- In a virtual host configuration block.

- In a <Directory> or <Location> block.

- In .htaccess, if AllowOverride Options is on.

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

### 6.18. Classic Ruby on Rails (⇐ 2.x)-specific options

These options only have effect on classic Ruby on Rails 1.x and 2.x applications. Ruby on Rails >= 3.x applications are considered Rack applications.

#### 6.18.1. RailsBaseURI <uri>

Used to specify that the given URI is a Rails application. See Deploying Rails to a sub URI for an example.

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

This option may occur in the following places:

- In the global server configuration.

- In a virtual host configuration block.

- In a <Directory> or <Location> block.

- In .htaccess, if AllowOverride Options is on.

#### 6.18.2. RailsEnv <string>

This option allows one to specify the default RAILS_ENV value.

This option may occur in the following places:

- In the global server configuration.

- In a virtual host configuration block.

- In a <Directory> or <Location> block.

- In .htaccess, if AllowOverride Options is on.

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

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

#### 6.19.1. RackBaseURI <uri>

Used to specify that the given URI is a Rack application. See Deploying Rack to a sub URI for an example.

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

This option may occur in the following places:

- In the global server configuration.

- In a virtual host configuration block.

- In a <Directory> or <Location> block.

- In .htaccess, if AllowOverride Options is on.

#### 6.19.2. RackEnv <string>

The given value will be accessible in Rack applications in the RACK_ENV environment variable. This allows one to define the environment in which Rack applications are run, very similar to RAILS_ENV.

This option may occur in the following places:

- In the global server configuration.

- In a virtual host configuration block.

- In a <Directory> or <Location> block.

- In .htaccess, if AllowOverride Options is on.

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

### 6.20. Deprecated or removed options

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

#### 6.20.1. RailsRuby

Deprecated in favor of PassengerRuby.

#### 6.20.2. RailsUserSwitching

Deprecated in favor of PassengerUserSwitching.

#### 6.20.3. RailsDefaultUser

Deprecated in favor of PassengerDefaultUser.

#### 6.20.4. RailsAllowModRewrite

This option doesn’t do anything anymore in recent versions of Phusion Passenger.

#### 6.20.5. RailsSpawnMethod

Deprecated in favor of PassengerSpawnMethod.

#### 6.20.6. RailsAutoDetect, RackAutoDetect and WsgiAutoDetect

These options have been removed in version 4.0.0 as part of an optimization. You should use PassengerEnabled instead.

#### 6.20.7. RailsAppSpawnerIdleTime

This option has been removed in version 4.0.0, and replaced with PassengerMaxPreloaderIdleTime.

#### 6.20.8. RailsFrameworkSpawnerIdleTime

This option is no longer available in version 4.0.0. There is no alternative because framework spawning has been removed altogether. You should use smart spawning instead.

## 7. Troubleshooting

### 7.1. Operating system-specific problems

#### 7.1.1. MacOS X: The installer cannot locate MAMP’s Apache

Symptoms

The installer finds Apache 2 development headers at /Applications/MAMP/Library/bin/apxs. However, Apache cannot be found. The installer also outputs the following error:

    cannot open /Applications/MAMP/Library/build/config_vars.mk:
    No such file or directory at /Applications/MAMP/Library/bin/apxs line 218.

Your MAMP installation seems to be broken. In particular, config_vars.mk is missing. Please read this forum topic to learn how to fix this problem.

See also this bug report.

### 7.2. Problems during installation

#### 7.2.1. Ruby development headers aren’t installed

Symptoms

Installing Phusion Passenger fails because of one of the following errors:

- The Phusion Passenger installer tells you that the Ruby development headers aren’t installed.

- The error message “'no such file to load — mkmf”' occurs.

- The error message “'ruby.h: No such file or directory”' occurs.

Phusion Passenger makes use of a native extension, so the Ruby development headers must be installed. On most Linux systems, Ruby and the Ruby development headers are contained in separate packages, so having Ruby installed does not automatically imply having the development headers installed.

Here’s how you can install the development headers:

Ubuntu/Debian

  Please type:

      sudo apt-get install ruby1.8-dev

Fedora/CentOS/RHEL

  Please type:

      su -c 'yum install ruby-devel'

FreeBSD

  Please install Ruby from ports or with pkg_add. If that fails, please install Ruby from source.

MacOS X

  Please install Ruby from source.

Other operating systems

  Please consult your operating system’s native package database. There should be a package containing the Ruby development headers. If that fails, please install Ruby from source.

| If you’ve installed a new Ruby version (i.e. your system now contains multiple Ruby installations), then you will need to tell Phusion Passenger which Ruby installation you want to use. Please read Specifying the correct Ruby installation.

#### 7.2.2. Apache development headers aren’t installed

Symptoms

Installing Phusion Passenger fails because of one of the following errors:

- The installer says that the Apache development headers aren’t installed.

- The error message “'httpd.h: No such file or directory”' occurs.

  (Instead of httpd.h, the message might also be http_config.h or something else similar to http_*.h.)

Ubuntu

  Please type:

      sudo apt-get install apache2-prefork-dev

Debian

  Please type:

      sudo apt-get install apache2-dev

Fedora/CentOS/RHEL

  Please type:

      su -c 'yum install httpd-devel'

FreeBSD

  Please install Apache from ports or with pkg_add. If that fails, please install Apache from source.

MacOS X

  Please install Apache from source.

Other operating systems

  Please consult your operating system’s native package database. There should be a package containing the Apache development headers. If that fails, please install Apache from source.

#### 7.2.3. APR development headers aren’t installed

Symptoms

Installing Phusion Passenger fails because one of the following errors:

- The installer tells you that APR development headers aren’t installed.

- The error message “'apr_pools.h: No such file or directory”' occurs.

- The error message “'apr_strings.h: No such file or directory”' occurs.

Ubuntu

  Please type:

      sudo apt-get install libapr1-dev

Debian

  Please type:

      sudo apt-get install libapr1-dev

Fedora/CentOS/RHEL

  Please type:

      su -c 'yum install apr-devel'

Other Linux distributions

  Please consult your distribution’s package database. There should be a package which provides APR development headers.

Other operating systems

  The APR development are bundled with Apache. If the APR headers aren’t, then it probably means that they have been removed after Apache’s been installed. Please reinstall Apache to get back the APR headers.

#### 7.2.4. Phusion Passenger is using the wrong Apache during installation

Please Specifying the correct Apache installation, and re-run the Phusion Passenger installer.

#### 7.2.5. Phusion Passenger is using the wrong Ruby during installation

Please Specifying the correct Ruby installation, and re-run the Phusion Passenger installer.

### 7.3. Problems after installation

| The golden tip: read your Apache error logs! mod_passenger will write all errors to the Apache error log. So if you’re experiencing post-installation problems, please look inside the Apache error logs. It will tell you what exactly went wrong.

#### 7.3.1. My Rails application works on Mongrel, but not on Phusion Passenger

Please try setting PassengerSpawnMethod to conservative.

#### 7.3.2. Phusion Passenger has been compiled against the wrong Apache installation

Symptoms

Apache crashes during startup (after being daemonized). The Apache error log says “'seg fault or similar nasty error detected in the parent process”'.

This problem is most likely to occur on MacOS X. Most OS X users have multiple Apache installations on their system.

To solve this problem, please specify the correct Apache installation, and reinstall Phusion Passenger.

#### 7.3.3. I get a "403 Forbidden" error

See next subsection.

#### 7.3.4. Static assets such as images and stylesheets aren’t being displayed

Static assets are accelerated, i.e. they are served directly by Apache and do not go through the Rails stack. There are two reasons why Apache doesn’t serve static assets correctly:

1. Your Apache configuration is too strict, and does not allow HTTP clients to access static assets. This can be achieved with an Allow from all directive in the correct place. For example:

       <Directory "/webapps/mycook/public">
          Options FollowSymLinks
          AllowOverride None
          Order allow,deny
          Allow from all
       </Directory>

   See also this discussion.

2. The Apache process doesn’t have permission to access your Rails application’s folder. Please make sure that the Rails application’s folder, as well as all of its parent folders, have the correct permissions and/or ownerships.

#### 7.3.5. The Apache error log says that the spawn manager script does not exist, or that it does not have permission to execute it

If you are sure that the PassengerRoot configuration option is set correctly, then this problem is most likely caused by the fact that you’re running Apache with SELinux. On Fedora, CentOS and RedHat Enterprise Linux, Apache is locked down by SELinux policies.

To solve this problem, you must set some permissions on the Phusion Passenger files and folders, so that Apache can access them.

- If you’ve installed Phusion Passenger via a gem, then run this command to determine Phusion Passenger’s root folder:

      passenger-config --root

  Next, run the following command:

      chcon -R -h -t httpd_sys_content_t /path-to-passenger-root

  where /path-to-passenger-root should be replaced with whatever passenger-config --root printed.

- If you’ve installed Phusion Passenger via the source tarball, then run the following command:

      chcon -R -h -t httpd_sys_content_t /path/to/passenger/folder

Once the permissions are fixed, restart Apache.

#### 7.3.6. The Rails application reports that it’s unable to start because of a permission error

Please check whether your Rails application’s folder has the correct permissions. By default, Rails applications are started as the owner of the file config/environment.rb, except if the file is owned by root. If the file is owned by root, then the Rails application will be started as nobody (or as the user specify by RailsDefaultUser, if that’s specified).

Please read User switching (security) for details.

#### 7.3.7. My Rails application’s log file is not being written to

There are a couple things that you should be aware of:

- By default, Phusion Passenger runs Rails applications in production mode, so please be sure to check production.log instead of development.log. See RailsEnv for configuration.

- By default, Phusion Passenger runs Rails applications as the owner of environment.rb. So the log file can only be written to if that user has write permission to the log file. Please chmod or chown your log file accordingly.

  See User switching (security) for details.

If you’re using a RedHat-derived Linux distribution (such as Fedora or CentOS) then it is possible that SELinux is interfering. RedHat’s SELinux policy only allows Apache to read/write directories that have the httpd_sys_content_t security context. Please run the following command to give your Rails application folder that context:

    chcon -R -h -t httpd_sys_content_t /path/to/your/rails/app

#### 7.3.8. I’ve deployed my app on SSL, but the app thinks its not on SSL

Rails and many other frameworks infers whether it’s running on SSL through the CGI environment variable HTTPS. Apache always sets this variable when on SSL, except when SSL is incorrectly configured.

Most Apache installations already configure SSL by default on port 443 (conf/extra/httpd-ssl.conf). Some people think they can save some typing in subsequent SSL vhost blocks, and omit important options like SSLEngine on, like this:

    # httpd-ssl.conf contains something like:
    # <VirtualHost _default_:443>
    #     SSLEngine on
    #     ...
    # </VirtualHost>
    Include conf/extra/httpd-ssl.conf

    <VirtualHost *:443>
        ServerName www.example.com
        DocumentRoot /webapps/example/public
    </Virtualhost>

This is wrong! In each SSL vhost block you must re-specify all the SSL options. Otherwise Apache won’t properly detect the vhost as an SSL vhost block. Here’s the corrected example:

    Include conf/extra/httpd-ssl.conf

    <VirtualHost *:443>
        ServerName www.example.com
        DocumentRoot /webapps/example/public
        SSLEngine on
        ...more SSL options here...
    </Virtualhost>

### 7.4. Conflicting Apache modules

#### 7.4.1. mod_userdir

mod_userdir is not compatible with Phusion Passenger at the moment.

#### 7.4.2. MultiViews (mod_negotiation)

MultiViews is not compatible with Phusion Passenger. You should disable MultiViews for all Phusion Passenger hosts.

#### 7.4.3. VirtualDocumentRoot

VirtualDocumentRoot is not compatible with Phusion Passenger at the moment.

## 8. Analysis and system maintenance

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

### 8.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 the web server’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

    ----------- Nginx processes ------------.
    PID    PPID   VMSize     Resident  Name
    ----------------------------------------.
    51766  51764  82.7 MB    3.9 MB    nginx: master process ./objs/nginx
    51773  51766  82.9 MB    0.9 MB    nginx: worker process

    --------- 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 and Nginx worker processes only take less than 1 MB memory each. This is a lot less than the 50-80 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.

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

The most likely reason why a spike occurs is because your application is frozen, i.e. it has stopped responding. See Debugging frozen applications for tips.

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

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

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

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

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.

## 9. Tips

### 9.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 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 the web server is started by root. This is the case on most 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 PassengerDefaultUser and PassengerDefaultGroup.

User switching can be disabled with the PassengerUserSwitching option.

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

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

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

### 9.5. Installing multiple Ruby on Rails versions

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

    gem install rails -v X.X.X

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

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

### 9.6. Making the application restart after each request

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

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

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

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

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

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

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

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

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

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

### 9.8. Out-of-Band Garbage Work and Out-of-Band Garbage Collection

Available since Phusion Passenger 4.0.0.

At this time, this feature is only available on Ruby.

The Out-of-Band Work feature allows you to run arbitrary long-running tasks outside normal request cycles. This works by letting current requests to the process finish, then telling the process to perform the out-of-band work, then resuming passing requests to the process after said work is finished.

A specific (and perhaps primary) use case of of Out-of-Band Work is Out-of-Band Garbage Collection. The garbage collector is run outside normal request cycles so that garbage collection runs inside normal request cycles can finish a lot faster. This can potentially save tens to hundreds of milliseconds of latency in requests.

Because Out-of-Band Work is implemented at the Phusion Passenger inter-process request routing level, and not by, say, spawning a thread inside the application process, Out-of-Band Work has the following useful properties:

- It works well even with tasks that can pause all threads. The MRI Ruby garbage collector is a stop-the-world mark-and-sweep garbage collector.

- Phusion Passenger can spawn more processes as necessary, in order to prevent situations in which all application processes are busy performing out-of-band work. Phusion Passenger guarantees that there’s at least one process that’s ready to process requests.

Applications can use Out-of-Band Work as follows:

1. Request out-of-band work by outputting the X-Passenger-Request-OOB-Work header during a request. It does not matter what the value is. At this time, it is not possible to request out-of-band work from outside requests.

2. You can actually perform out-of-band work when you receive a :oob_work Phusion Passenger event.

Note that even though you can request out-of-band work, there’s no guarantee that Phusion Passenger will send an oob_work event in a timely manner, if at all. It is also possible that Phusion Passenger sends an oob_work event without you ever having requested one. This latter could for example happen if the OOB work is administrator-initiated. Do not make any assumptions in your code.

Here’s an example which implements out-of-band garbage collection using the Out-of-Band framework:

    # Somewhere in a controller method:
    # Tell Phusion Passenger we want to perform OOB work.
    response.headers["X-Passenger-Request-OOB-Work"] = "true"

    # Somewhere during application initialization:
    PhusionPassenger.on_event(:oob_work) do
      # Phusion Passenger has told us that we're ready to perform OOB work.
      t0 = Time.now
      GC.start
      Rails.logger.info "Out-Of-Bound GC finished in #{Time.now - t0} sec"
    end

For your convenience, Phusion Passenger provides a Rack middleware for out-of-band garbage collection. Add this to your config.ru:

    require 'phusion_passenger/rack/out_of_band_gc'

    # Trigger out-of-band GC every 5 requests.
    use PhusionPassenger::Rack::OutOfBandGc, 5

References:

- The Phusion Blog article which first introduced this feature.

### 9.9. X-Sendfile support

Phusion Passenger does not provide X-Sendfile support by itself. Please install mod_xsendfile for X-Sendfile support.

### 9.10. Upload progress

Phusion Passenger does not provide upload progress support by itself. Please try drogus’s Apache upload progress module instead.

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

### 10.1. Static assets serving

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

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

    # Check whether this request has a corresponding file; if that
    # exists, let Apache serve it, otherwise forward the request to
    # Mongrel.
    RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
    RewriteRule ^(.*)$ balancer://mongrel%{REQUEST_URI} [P,QSA,L]

These kind of mod_rewrite rules are no longer required, and you can safely remove them.

### 10.2. 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 the web server 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 the web server 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.

### 10.3. 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 DocumentRoot 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 DocumentRoot directory.

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

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

Note that Phusion Passenger does not resolve any symlinks in the document root path by default since version 2.2.0 — in contrast to versions earlier than 2.2.0, which do resolve symlinks. So for example, suppose that your DocumentRoot points to /home/www/example.com, which in turn is a symlink to /webapps/example.com/public. In versions earlier than 2.2.0, Phusion Passenger will check whether /webapps/example.com/config/environment.rb exists because it resolves all symlinks. Phusion Passenger 2.2.0 and later however will check for /home/www/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 an Apache mod_dirindex directory listing.

If you need the old symlink-resolving behavior for whatever reason, then you can turn on PassengerResolveSymlinksInDocumentRoot.

Another way to solve this situation is to explicitly tell Phusion Passenger what the correct application root is through the PassengerAppRoot configuration directive.

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

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

## 12. Appendix B: Terminology

### 12.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
       |
       +- ...

### 12.2. Idle process

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

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

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

### 13.1. The most straightforward and traditional way: direct 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 direct 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().

### 13.2. The smart spawning method

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

While direct 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 direct 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 spawn method.

#### 13.2.1. How it works

When the smart 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 spawn method. All worker processes, as well as the ApplicationSpawner, share the same application code and Rails framework code.

The smart method allows different worker processes that belong to the same application to share memory.

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

#### 13.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 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 direct 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.

In practice, the smart spawning method 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.

### 13.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 direct 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.

#### 13.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 direct spawning mode. We don't need to do anything.
            end
        end
    end

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

### 13.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 direct spawning mode. We don't need to do anything.
            end
        end
    end

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