1. Support information

1.1. Supported operating systems and languages

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

Supported operating systems:

OS Minimum version

Ubuntu

10.04

Debian

6

Red Hat, CentOS

5

Amazon Linux

All versions supported

Mac OS X

10.8 Mountain Lion

FreeBSD

8

OpenBSD

5.2

Other Unix

-

"Other Unix" is supported on a "best-effort" basis. We do not regularly check whether Phusion Passenger still works on other Unices, but if users report issues then we’ll try to address them.

Supported architectures:

Architecture Notes

x86 (32-bit)

-

x86_64 (64-bit)

-

Other

Supported on a "best-effort" basis.

Supported languages and frameworks:

Language/framework Minimum version

Ruby (MRI)

1.8.5

JRuby

1.7.0

Rubinius

2.2.0

Ruby on Rails

2.3

Python

2.6

Node.js/io.js

0.10

Meteor

0.6

If you run into any issues, please report a bug or join our discussion forum.

1.2. Where to get support

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

  • Issue tracker - report bugs here.

  • 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 security@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

Because Phusion Passenger is designed to run in a wide variety of operating systems and configurations, there are multiple ways to install it. Most users  — especially first-time users — will prefer OS-specific installation instructions. These are not only the easiest, but also allow Phusion Passenger to integrate into the operating system in the best way possible. Other users should consult the generic installation instructions.

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. Installing or upgrading on Mac OS X with Homebrew

Open source

Every time we release a new Phusion Passenger version, we make it available through Homebrew. Please note that the Homebrew maintainers have to merge our pull requests manually, so it may take a day or two before a new version shows up in the official Homebrew repository.

  1. Update the Homebrew recipes:

    brew update
  2. Run one of the following, and follow the instructions:

    brew install passenger
    -OR-
    brew upgrade passenger
Enterprise

Phusion Passenger Enterprise is currently not available through Homebrew. Please try one of the other installation methods instead.

2.3. Installing or upgrading on Debian or Ubuntu

We provide an official Phusion Passenger APT repository. This APT repository contains Phusion Passenger packages for multiple versions of Debian and Ubuntu. These packages are automatically built by our build server after we push out a source release, and thus are always up to date with the official source releases.

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.

Packages are available for the x86 and x86_64 architectures. Our policy is to support all Ubuntu LTS releases that are still supported by Canonical, plus the latest Ubuntu release, plus all Debian releases that are still supported by Debian.

2.3.1. Adding our APT repository

  1. Install our PGP key. Packages are signed by "Phusion Automated Software Signing (auto-software-signing@phusion.nl)", fingerprint 1637 8A33 A6EF 1676 2922 526E 561F 9B9C AC40 B2F7.

    sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 561F9B9CAC40B2F7
  2. Add HTTPS support for APT. Our APT repository is stored on an HTTPS server.

    sudo apt-get install apt-transport-https ca-certificates
  3. Create a file /etc/apt/sources.list.d/passenger.list and insert one of the following lines, depending on your distribution.

    Open source
    ##### !!!! Only add ONE of these lines, not all of them !!!! #####
    # Ubuntu 15.04
    deb https://oss-binaries.phusionpassenger.com/apt/passenger vivid main
    # Ubuntu 14.04
    deb https://oss-binaries.phusionpassenger.com/apt/passenger trusty main
    # Ubuntu 12.04
    deb https://oss-binaries.phusionpassenger.com/apt/passenger precise main
    # Debian 8
    deb https://oss-binaries.phusionpassenger.com/apt/passenger jessie main
    # Debian 7
    deb https://oss-binaries.phusionpassenger.com/apt/passenger wheezy main
    # Debian 6
    deb https://oss-binaries.phusionpassenger.com/apt/passenger squeeze main
    Enterprise
    ##### !!!! Only add ONE of these lines, not all of them !!!! #####
    # Ubuntu 15.04
    deb https://download:YOUR_DOWNLOAD_TOKEN@www.phusionpassenger.com/enterprise_apt vivid main
    # Ubuntu 14.04
    deb https://download:YOUR_DOWNLOAD_TOKEN@www.phusionpassenger.com/enterprise_apt trusty main
    # Ubuntu 12.04
    deb https://download:YOUR_DOWNLOAD_TOKEN@www.phusionpassenger.com/enterprise_apt precise main
    # Debian 8
    deb https://download:YOUR_DOWNLOAD_TOKEN@www.phusionpassenger.com/enterprise_apt jessie main
    # Debian 7
    deb https://download:YOUR_DOWNLOAD_TOKEN@www.phusionpassenger.com/enterprise_apt wheezy main
    # Debian 6
    deb https://download:YOUR_DOWNLOAD_TOKEN@www.phusionpassenger.com/enterprise_apt squeeze main

    You can find the correct value for YOUR_DOWNLOAD_TOKEN in the Customer Area.

  4. Secure passenger.list and update your APT cache:

    sudo chown root: /etc/apt/sources.list.d/passenger.list
    sudo chmod 600 /etc/apt/sources.list.d/passenger.list
    sudo apt-get update
  5. (Optional) If using unattended-upgrades, add our APT repository to the list of Allowed-Origins for upgrades, /etc/apt/apt.conf.d/50unattended-upgrades:

    // Automatically upgrade packages from these (origin:archive) pairs
    Unattended-Upgrade::Allowed-Origins {
      // To check "Origin:" and "Suite:", you could use e.g.:
      // grep "Origin\|Suite" /var/lib/apt/lists/oss-binaries.phusionpassenger.com*
      "Phusion:stable";
    };

2.3.2. Installing packages

Open source
  1. Add our APT repository.

  2. Install the package:

    sudo apt-get install libapache2-mod-passenger
  3. Enable the Phusion Passenger Apache module and stop/start Apache (reload or restart is not enough when upgrading):

    sudo a2enmod passenger
    sudo apache2ctl stop; sudo apache2ctl start
Enterprise
  1. Download your license key from the Customer Area and save it as /etc/passenger-enterprise-license.

  2. Add our APT repository.

  3. Install the packages:

    sudo apt-get install libapache2-mod-passenger-enterprise
  4. Enable the Phusion Passenger Apache module and stop/start Apache (reload or restart is not enough when upgrading):

    sudo a2enmod passenger
    sudo apache2ctl stop; sudo apache2ctl start

You can now proceed with a chapter for Deploying your (specific type of) application.

2.4. Installing or upgrading on Red Hat or CentOS

We provide an official Phusion Passenger YUM repository with packages for Red Hat Enterprise Linux and CentOS. These packages are automatically built by our build server after we push out a source release, and thus are always up to date with the official source releases.

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. These packages also come with SELinux policy modules so that Passenger works nicely with SELinux.

Packages are available for the x86 and x86_64 architectures. Our policy is to support all Red Hat and CentOS releases that still receive full updates by their vendors. The earliest Red Hat and CentOS version we support is version 5.

2.4.1. Adding our YUM repository

  1. Install EPEL and a few other prerequisites.

    sudo yum install epel-release pygpgme curl
  2. Download the Passenger YUM repository definition.

    Open source
    sudo curl --fail -sSLo /etc/yum.repos.d/passenger.repo https://oss-binaries.phusionpassenger.com/yum/definitions/el-passenger.repo
    Enterprise
    unset HISTFILE
    sudo curl --fail -sSL -u download:YOUR_DOWNLOAD_TOKEN -o /etc/yum.repos.d/passenger.repo https://www.phusionpassenger.com/enterprise_yum/el-passenger-enterprise.repo

    The unset HISTFILE command ensures that your download token isn’t saved to the Bash history file.

    You can find the correct value for YOUR_DOWNLOAD_TOKEN in the Customer Area.

  3. Secure passenger.repo:

    sudo chown root: /etc/yum.repos.d/passenger.repo
    sudo chmod 600 /etc/yum.repos.d/passenger.repo

2.4.2. Installing packages

Note
Notes about SELinux on Red Hat 6 and CentOS 6

If you are on Red Hat 6 or CentOS 6, and you are also using SELinux in enforcing mode, then Passenger requires kernel >= 2.6.39.

If you want to install Passenger on Red Hat 6 or CentOS 6, without upgrading your kernel, then you must disable SELinux completely. Edit /etc/selinux/config, set SELINUX=disabled and reboot. Note that merely setting SELinux to permissive mode is not enough.

This issue does not apply to Red Hat >= 7 and CentOS >= 7, because these OS versions supply recent enough kernel versions.

You can install the Passenger packages as follows.

Open source
  1. Add our YUM repository.

  2. Install the package:

    sudo yum install mod_passenger
  3. Stop/start Apache (reload or restart is not enough when upgrading):

    sudo service httpd stop; sudo service httpd start
Enterprise
  1. Download your license key from the Customer Area and save it as /etc/passenger-enterprise-license.

  2. Add our YUM repository.

  3. Install the packages:

    sudo yum install mod_passenger_enterprise
  4. Stop/start Apache (reload or restart is not enough when upgrading):

    sudo service httpd stop; sudo service httpd start

You can now proceed with a chapter for Deploying your (specific type of) application.

2.5. Installing or upgrading on Heroku

Please refer to our Heroku Ruby demo for installation and upgrade instructions for Heroku.

2.6. 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. This is explained in Phusion Passenger and its relationship with Ruby.

Step 1: figuring out whether your Ruby is installed in 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 -H bash

  • Are you not using RVM, or do you not know what RVM is? Run sudo -H -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
Previous versions and beta versions

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

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

Next, add the Phusion Passenger Enterprise gem server to your RubyGems source list:

gem source --add https://download:YOUR_DOWNLOAD_TOKEN@www.phusionpassenger.com/enterprise_gems/

Substitute YOUR_DOWNLOAD_TOKEN with the one you find in the Customer Area. And notice the trailing slash in the URL! It is very important.

Finally, install the latest gem to obtain the files for the latest stable version of Passenger Enterprise:

gem install passenger-enterprise-server
Previous versions and beta versions

Sometimes you will want to obtain the latest beta version of Phusion Passenger Enterprise. 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-enterprise-server --pre

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

gem install passenger-enterprise-server --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-enterprise-server --version 3.9.1.beta --pre

Step 3: 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 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 4: restarting the Flying Passenger daemon

If you are using Flying Passenger then you must restart the Flying Passenger daemon by sending it the SIGTERM signal:

kill `cat /path-to/flying-passenger.pid`

Or, if Flying Passenger is not running with a PID file, look up its PID us ps and then send it SIGTERM:

ps aux | grep flying-passenger
kill PID_OF_FLYING_PASSENGER

Step 5: 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.7. Generic installation, upgrade and downgrade method: via tarball

Step 1: installing Ruby

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

Even though Ruby is required, Ruby will normally not be loaded during normal operation unless you deploy a Ruby web application on Phusion Passenger. Phusion Passenger’s dependency on Ruby is very minimal. See Phusion Passenger and its relationship with Ruby for details.

Debian, Ubuntu

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

Red Hat, CentOS, ScientificLinux, Amazon Linux

Enable EPEL, then run as root:
yum install ruby rubygem-rake

Mac OS X

No action needed. Ruby is installed by default.

Other operating systems

Install Ruby from the Ruby website.

Step 2: download and extract the tarball

Open Source

Download the open source Phusion Passenger tarball from the Phusion Passenger website.

Older versions can be found in the release archive.

Enterprise

Phusion Passenger Enterprise customers can 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. Create this directory and extract the tarball as follows:

mkdir /opt/passenger
cd /opt/passenger
tar xzvf /location-to/passenger-x.x.x.tar.gz
cd /opt/passenger/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 3: 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 Apache module.

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

./bin/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 4: verifying that Phusion Passenger is running

Restart your web server and run:

./bin/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.8. 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.9. Cryptographic verification of installation files

2.9.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.9.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.9.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: 8C59158F
Long key ID: CD70085E8C59158F
Fingerprint: 218A 7255 83D0 2ECE F3A9 C2A7 CD70 085E 8C59 158F
Ninh Bui (ninh@phusion.nl)
Short key ID: 69481265
Long key ID: AE405F7869481265
Fingerprint: A77C 9CEF 766D 0E7D A95B 8778 AE40 5F78 6948 1265

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

gpg --keyserver pool.sks-servers.net --search-keys 0xCD70085E8C59158F
gpg --keyserver pool.sks-servers.net --search-keys 0xAE405F7869481265
# -OR-
gpg --keyserver keyserver.ubuntu.com --search-keys 0xCD70085E8C59158F
gpg --keyserver keyserver.ubuntu.com --search-keys 0xAE405F7869481265

2.9.4. Verifying the gem and tarball

You can find the open source version’s gem and tarball GPG signatures at https://www.phusionpassenger.com/file_releases. 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.9.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.9.6. Verifying Debian packages

Our APT repository is signed by Phusion Automated Software Signing (auto-software-signing@phusion.nl). Packages are automatically checked upon installation.

2.9.7. Verifying RPM packages

Our YUM repository is signed by PackageCloud (ops@packagecloud.io). PackageCloud is the RPM package hosting service that we use. You can find their key here. Packages are automatically checked upon installation.

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

If you installed Phusion Passenger through our APT repository, then you should update APT’s keyring from time to time as well:

sudo apt-key adv --refresh-keys --keyserver keyserver.ubuntu.com

2.10. 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.11. Customizing the compilation process

The Phusion Passenger compilation process can be customized with environment variables. You can learn more about environment variables in About environment variables.

2.11.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'
Note If you run the installer with sudo then environment variables may not be passed properly. Learn more at Environment variables and sudo.

2.11.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 source files. This also covers 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/EXTRA_PRE_CXXFLAGS.

EXTRA_PRE_C_LDFLAGS

These flags are injected into all C compiler invocations that involve linking, right after EXTRA_PRE_LDFLAGS.

EXTRA_PRE_CXX_LDFLAGS

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

EXTRA_LDFLAGS

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

EXTRA_C_LDFLAGS

Similar to EXTRA_LDFLAGS, but only injected for C executable linking commands. Injected right after EXTRA_LDFLAGS.

EXTRA_CXX_LDFLAGS

Similar to EXTRA_LDFLAGS, but only injected for C++ executable linking commands. Injected right after EXTRA_LDFLAGS.

PASSENGER_THREAD_LOCAL_STORAGE

Setting this to 1 will enable the PASSENGER_THREAD_LOCAL_STORAGE macro, which forcefully disables the use of thread-local storage inside the Phusion Passenger codebase. Setting this environment variable is useful on systems that have broken support for thread-local storage, despite passing our build system’s check for proper thread-local storage support. At the time of writing, one user has reported that Ubuntu 12.04 32-bit has broken thread-local storage report although neither the reporter nor us were able to reproduce the problem on any other systems running Ubuntu 12.04 32-bit. Note that this flag has no effect on non-Phusion Passenger code.

Note If you run the installer with sudo then environment variables may not be passed properly. Learn more at Environment variables and sudo.

2.11.3. Forcing location of command line tools and dependencies

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 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). Only used by passenger-install-apache2-module.

This environment variable, together with HTTPD, are what you need to customize if you have multiple Apache installations on your system, or if your Apache is located in a non-standard location which Phusion Passenger cannot detect. By setting APXS2 and HTTP to the right paths, you can force Phusion Passenger to be compiled against that specific Apache installation.

For example, if your Apache installation is located in /opt/lamp/apache2, then you can run the installer as follows:

$ sudo bash
# export HTTPD=/opt/lampp/apache2/bin/apache
# export APXS2=/opt/lampp/apache2/bin/apxs
# passenger-install-apache2-module
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.

Tip If you do not know what environment variables are, or how to use them, then please read Environment variables and sudo.
Note If you run the installer with sudo then environment variables may not be passed properly. Learn more at Environment variables and sudo.

2.12. Dealing with multiple Apache installations

Some systems have multiple Apache installations. Maybe you already know about that, and you installed multiple Apaches for a reason. Or maybe you did so in the past but then forgot about the other installs. Or maybe someone else — or some other software — installed another Apache for you without your knowledge.

Whatever the reason might be, it is important that you know about the existance of multiple Apache installations, and that you decide which one you want to use. Unless you know exactly what you are doing, we recommend that you remove all the Apache installations that you don’t intend to use, in order to avoid confusion and problems. You should end up with only a single Apache installation. Unfortunately, this manual cannot tell you how to remove the other Apache installs: it depends on how you originally installed them. Usually it’s a matter of removing the directories that they’re located in, and removing their configuration files. But some Apache distributions might bundle an uninstaller. You need to do the proper research on how they ended up there in the first place.

Phusion Passenger provides a tool to check whether you have multiple Apache installations on your system. You can invoke the tool by running passenger-config --detect-apache2.

If the existance of multiple Apache installations is intentional, then Phusion Passenger can happily go along with your choice: you simply have to tell passenger-install-apache2-module which Apache to install against. There are several ways to specify which Apache you want to install against:

  • By passing the --apxs2-path parameter. The passenger-config --detect-apache2 command will tell you how to use this parameter.

  • By setting APXS2, HTTPD and other kinds of environment variables. Please refer to Forcing location of command line tools and dependencies for more information.

2.13. 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.14. 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 go 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.15. 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 through Homebrew, then run brew uninstall passenger. Then run rm -f /etc/apache2/other/passenger.conf.

  • If you installed Phusion Passenger via a Ruby gem, then run gem uninstall passenger (or, if you’re a 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.16. 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 Apache 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.

If you used the tarball installation method and you added Phusion Passenger’s bin subdirectory to PATH, then you must update your PATH with the new location. Open /etc/bashrc (or /etc/bash.bashrc on some systems) and change:

export PATH=/opt/passenger/passenger-4.0.0/bin:$PATH

to:

export PATH=/usr/local/passenger-4.0.0/bin:$PATH

Finally, restart all your shell sessions to activate the PATH change.

3. Deploying a Rack-based Ruby application

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

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

3.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
        # Uncomment this if you're on Apache >= 2.4:
        #Require all granted
    </Directory>
</VirtualHost>

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

3.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
        # Uncomment this if you're on Apache >= 2.4:
        #Require all granted
    </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.

3.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
        Options -MultiViews
        # Uncomment this if you're on Apache >= 2.4:
        #Require all granted
    </Directory>
</VirtualHost>

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

To do this, you need to perform the following:

  1. Set Alias {SUBURI} {PATH TO YOUR APPLICATION'S PUBLIC DIRECTORY}.

  2. Create a <Location /{SUBURI}> block.

  3. Inside the Location block, set PassengerBaseURI /{SUBURI}.

  4. Inside the Location block, set PassengerAppRoot {PATH TO YOUR APPLICATION ROOT}.

  5. Create a <Directory {PATH TO YOUR APPLICATION'S PUBLIC DIRECTORY}> block.

  6. Inside the Directory block, set Allow from all, and (if you’re on Apache >= 2.4) Require all granted.

  7. Inside the Directory block, disable MultiViews.

Here is an example:

<VirtualHost *:80>
    ServerName www.phusion.nl
    DocumentRoot /websites/phusion
    <Directory /websites/phusion>
        Allow from all
        Options -MultiViews
        # Uncomment this if you're on Apache >= 2.4:
        #Require all granted
    </Directory>

    # These have been added:
    Alias /subapp /websites/rack/public
    <Location /subapp>
        PassengerBaseURI /subapp
        PassengerAppRoot /websites/rack
    </Location>
    <Directory /websites/rack/public>
        Allow from all
        Options -MultiViews
        # Uncomment this if you're on Apache >= 2.4:
        #Require all granted
    </Directory>
</VirtualHost>

Then restart Apache. The application has now been deployed to the sub-URI.

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

3.5. Rackup specifications for various web frameworks

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

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

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

3.5.3. Mack

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

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

3.5.5. Ramaze

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

3.5.6. Sinatra

require 'rubygems'
require 'sinatra'

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

require 'app.rb'

run Sinatra::Application

4. 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
  |
  +-- passenger_wsgi.py
  |
  +-- public/
  |
  +-- tmp/

4.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
        # Uncomment this if you're on Apache >= 2.4:
        #Require all granted
    </Directory>
</VirtualHost>

And we’re done! After an Apache restart, the above WSGI application will be available under the URL http://www.wsgiexample.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 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
        # Uncomment this if you're on Apache >= 2.4:
        #Require all granted
    </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.

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
        Options -MultiViews
        # Uncomment this if you're on Apache >= 2.4:
        #Require all granted
    </Directory>
</VirtualHost>

And you want your Python application, located in /websites/python, to be accessible from the URL http://www.phusion.nl/subapp.

To do this, you need to perform the following:

  1. Set Alias {SUBURI} {PATH TO YOUR APPLICATION'S PUBLIC DIRECTORY}.

  2. Create a <Location /{SUBURI}> block.

  3. Inside the Location block, set PassengerBaseURI /{SUBURI}.

  4. Inside the Location block, set PassengerAppRoot {PATH TO YOUR APPLICATION ROOT}.

  5. Create a <Directory {PATH TO YOUR APPLICATION'S PUBLIC DIRECTORY}> block.

  6. Inside the Directory block, set Allow from all, and (if you’re on Apache >= 2.4) Require all granted.

  7. Inside the Directory block, disable MultiViews.

Here is an example:

<VirtualHost *:80>
    ServerName www.phusion.nl
    DocumentRoot /websites/phusion
    <Directory /websites/phusion>
        Allow from all
        Options -MultiViews
        # Uncomment this if you're on Apache >= 2.4:
        #Require all granted
    </Directory>

    # These have been added:
    Alias /subapp /websites/python/public
    <Location /subapp>
        PassengerBaseURI /subapp
        PassengerAppRoot /websites/python
    </Location>
    <Directory /websites/python/public>
        Allow from all
        Options -MultiViews
        # Uncomment this if you're on Apache >= 2.4:
        #Require all granted
    </Directory>
</VirtualHost>

Then restart Apache. The application has now been deployed to the sub-URI.

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

4.5. Sample passenger_wsgi.py for Django

For Django applications, passenger_wsgi.py should look like this:

import myproject.wsgi
application = myproject.wsgi.application

Replace myproject with your project’s module name.

5. Deploying a Node.js application

Please refer to the Node.js tutorial.

6. Deploying a Meteor application

Please refer to the Meteor tutorial.

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

7.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. If you do not set this option, or if you set this option to the wrong value, then Phusion Passenger will make Apache abort with an error.

While installing Phusion Passenger, you have been told to set this option in your Apache configuration file, and you have been told what value to set it to. So under normal conditions, you don’t have ask yourself what value to set for this option. But in case you lost the value (e.g. because you accidentally removed the Apache configuration file, and you are trying to reconstruct it), or in case you didn’t follow the installation instructions correctly, then here’s how you can find out the correct value:

  • If you installed Phusion Passenger through our APT repository, then the value can be obtained by running /usr/bin/passenger-config --root.

  • If you installed Phusion Passenger through RubyGems, then the value can be obtained by running passenger-config --root.

  • If you installed Phusion Passenger through the source tarball, then the value is the path to the Phusion Passenger directory. For example, if you extracted the tarball’s contents to /opt/passenger/passenger-x.x.x, then passenger_root must be /opt/passenger/passenger-x.x.x.

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.

7.2. PassengerDefaultRuby <filename>

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.

7.3. Deployment options

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

7.3.2. PassengerBaseURI <uri>

Used to specify that the given URI is a Phusion Passenger-served application. Please refer to the following sections for examples:

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.

7.4. Application loading options

7.4.1. PassengerRuby <filename>

The PassengerDefaultRuby and PassengerRuby directives specify the Ruby interpreter to use. Similarly, the PassengerPython and PassengerNodejs directives are for specifying the Python interpreter and the Node.js command, respectively.

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. You can learn more about the internal helper scripts in Phusion Passenger and its relationship with Ruby.

It is okay if PassengerDefaultRuby refers to a different Ruby interpreter than the one you originally installed Phusion Passenger with. This too is explained in Phusion Passenger and its relationship with Ruby.

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 etc 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 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
# Use /usr/bin/node by default.
PassengerNodejs /usr/bin/node;

<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
    Alias /blog /websites/blog/public
    <Location /blog>
        PassengerBaseURI /blog
        PassengerAppRoot /websites/blog

        PassengerRuby /usr/local/rvm/wrappers/jruby-1.7.1/ruby
    </Location>
    <Directory /websites/blog/public>
        Allow from all
        Options -MultiViews
        # Uncomment this if you're on Apache >= 2.4:
        #Require all granted
    </Directory>
</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


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


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

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

7.4.3. PassengerNodejs <filename>

Introduced in version 4.0.24.

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

7.4.4. PassengerMeteorAppSettings <filename>

Introduced in version 5.0.7.

When using a Meteor application in non-bundled mode, use this option to specify a (JSON) file with settings for the application. Meteor will be started with the --settings parameter set to this option.

N.B. For bundled mode, Meteor requires you to put applications settings in the METEOR_SETTINGS environment variable.

7.4.5. PassengerAppEnv <string>

This option sets the value of the following environment variables:

  • RAILS_ENV

  • RACK_ENV

  • WSGI_ENV

  • NODE_ENV

  • PASSENGER_APP_ENV

Some web frameworks, for example Rails and Connect.js, adjust their behavior according to the value in one of these environment variables.

Phusion Passenger for Apache sets the default value to production. If you’re developing an Rails application then you should set this to development.

If you want to set other environment variables, please refer to Setting environment variables for Phusion Passenger-served apps.

Setting this option also adds the application environment name to the default application group name, so that you can run multiple versions of your application with different application environment names.

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.

7.4.6. RailsEnv <string>

An alias for PassengerAppEnv.

7.4.7. RackEnv <string>

An alias for PassengerAppEnv.

7.4.8. 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
    # Normally Phusion Passenger would have assumed that the
    # application root is "/var/rails/zena/sites/example.com".
    # This overrides it.
    PassengerAppRoot /var/rails/zena
</VirtualHost>

7.4.9. PassengerAppGroupName <name>

Sets the name of the application group that the current application should belong to. Its default value is the application root, plus (if it is set), the application environment name.

Phusion Passenger stores and caches most application spawning settings — such as environment variables, process limits, etc — on a per-app-group-name basis. This means that if you want to start two versions of your application, with each version having different environment variables, then you must assign them under different application group names.

For example, consider a situation in which you are running multiple versions of the same app, with each version intended for a different customer. You use the CUSTOMER_NAME environment variable to tell the app which customer that version should serve.

# WRONG example! Doesn't work!

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

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

This example doesn’t work, because Phusion Passenger thinks that they are the same application. When a user visits customer1.foo.com, Phusion Passenger will start a process with CUSTOMER_NAME=customer1. When another user visits customer2.foo.com, Phusion Passenger will route the request to the application process that was started earlier. Because environment variables are only set during application process startup, the second user will be served the website for customer 1.

To make this work, assign unique application group names:

<VirtualHost *:80>
    ServerName customer1.foo.com
    DocumentRoot /webapps/foo/public
    SetEnv CUSTOMER_NAME customer1
    PassengerAppGroupName foo_customer1
</VirtualHost>

<VirtualHost *:80>
    ServerName customer2.foo.com
    DocumentRoot /webapps/foo/public
    SetEnv CUSTOMER_NAME customer2
    PassengerAppGroupName foo_customer2
</VirtualHost>

Note that it is not necessary to set PassengerAppGroupName if you want to run two versions of your application under different application environment names, because the application environment name is included in the default application group name. For example, consider a situation in which you want to run a production and a staging version of your application. The following configuration will work fine:

<VirtualHost *:80>
    ServerName bar.com
    DocumentRoot /webapps/bar/public
    # Phusion Passenger implicitly sets:
    # PassengerAppGroupName /webapps/bar
</VirtualHost>

<VirtualHost *:80>
    ServerName staging.bar.com
    DocumentRoot /webapps/bar/public
    PassengerAppEnv staging
    # Phusion Passenger implicitly sets:
    # PassengerAppGroupName '/webapps/bar (staging)'
</VirtualHost>

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.

7.4.10. PassengerAppType <name>

Introduced in version 4.0.25.

By default, Phusion Passenger autodetects the type of the application, e.g. whether it’s a Ruby, Python, Node.js or Meteor app. If it’s unable to autodetect the type of the application (e.g. because you’ve specified a custom PassengerStartupFile) then you can use this option to force Phusion Passenger to recognize the application as a specific type.

Allowed values are:

  • rack - Ruby and Rails

  • wsgi - Python

  • node - Node.js, or Meteor JS in bundled mode

  • meteor - Meteor JS in non-bundled mode

If you set this option, then you must also set PassengerAppRoot, otherwise Phusion Passenger does not properly recognize your application.

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.

Example:

<VirtualHost test.host>
    DocumentRoot /webapps/example.com/public
    # Use server.js as the startup file (entry point file) for
    # your Node.js application, instead of the default app.js
    PassengerStartupFile server.js
    PassengerAppType node
    PassengerAppRoot /webapps/example.com
</VirtualHost>

7.4.11. PassengerStartupFile <filename>

Introduced in version 4.0.25.

This option specifies the startup file that Phusion Passenger should use when loading the application.

Every application has a startup file or entry point file: a file where the application begins execution. Some languages have widely accepted conventions about how such a file should be called (e.g. Ruby, with its config.ru). Other languages have somewhat-accepted conventions (e.g. Node.js, with its app.js). In these cases, Phusion Passenger reuses these conventions, and executes applications through those files.

Other languages have no conventions at all, and so Phusion Passenger invents one (e.g. Python WSGI with passenger_wsgi.py).

Here’s a list of the language-specific conventions that Phusion Passenger accepts:

Language Phusion Passenger convention

Ruby on Rails >= 3.0, Ruby Rack

config.ru

Ruby on Rails 1.x and 2.x

config/environment.rb

Python

passenger_wsgi.py

Node.js

app.js

But sometimes you might not want to adhere to the convention that Phusion Passenger accepts. For example, on Node.js, you might want to use server.js as the startup file instead of the default app.js. With this option, you can customize the startup file to any file you like.

Notes:

  • Customizing the startup file affects user switching. After all, if user switching is enabled, the application is executed as the user that owns the startup file.

  • If you set this option, you must also set PassengerAppRoot and PassengerAppType, otherwise Phusion Passenger doesn’t know what kind of application it is.

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.

Example:

<VirtualHost test.host>
    DocumentRoot /webapps/example.com/public
    # Use server.js as the startup file (entry point file) for
    # your Node.js application, instead of the default app.js
    PassengerStartupFile server.js
    PassengerAppType node
    PassengerAppRoot /webapps/example.com
</VirtualHost>

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

7.4.13. PassengerSpawnMethod <string>

Tip
"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 or Thin, but not on Phusion Passenger, then set PassengerSpawnMethod to direct. Otherwise, leave it at smart (the default).

However, we do recommend you to try to understand it. The smart spawn method 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 Phusion Passenger 4.0, 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.

7.4.14. PassengerLoadShellEnvvars <on|off>

Introduced in version 4.0.20.

Enables or disables the loading of shell environment variables before spawning the application.

If this option is turned on, and the user’s shell is bash, then applications are loaded by running them with bash -l -c. Otherwise, they are loaded by running them directly from the PassengerHelperAgent process.

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.

7.4.15. 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 through restart.txt. 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.

If Passenger Enterprise could not rolling restart a process (let’s call it A) because it is unable to spawn a new process (let’s call it B), then Passenger Enterprise will give up trying to rolling restart that particular process A. What happens next depends on whether deployment error resistance is enabled:

  • If deployment error resistance is disabled (the default), then Passenger Enterprise will proceed with trying to restart the remaining processes.

  • If deployment error resistance is enabled, the Passenger Enterprise will give up rolling restarting immediately. The application group will be put into Deployment Error Resistance Mode.

Please note that PassengerRollingRestarts is completely unrelated to the passenger-config restart-app command. That command always initiates a blocking restart, unless --rolling-restart is given.

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.

Note Are you looking to prevent applications from being restarted when you restart the web server? That is handled by the Flying Passenger mode (which requires Nginx), not by the rolling restarts feature.

7.4.16. 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 (Deployment Error Resistance Mode) 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. You can see whether the flag is set by invoking passenger-status. If you see the message "Resisting deployment error" then the flag is set.

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.

7.5. Security options

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

Warning If you’re on Red Hat or CentOS, be sure to read the Red Hat and CentOS user switching caveats.

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

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

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

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

7.5.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, a backtrace and a dump of the environment variables. 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. For this reason, friendly error pages are turned off by default when PassengerAppEnv (and its aliases such as RailsEnv and RackEnv) is set to staging or production, but enabled by default otherwise. You can use this option to explicitly enable or disable this feature.

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 depends on PassengerAppEnv (and its aliases such as RailsEnv and RackEnv), as documented above.

7.6. Resource control and optimization options

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

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

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

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

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

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

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

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

7.6.6. PassengerMaxPreloaderIdleTime <integer>

The preloader process(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 preloader’s idle timeout, in seconds. A value of 0 means that it should never idle timeout.

Setting a higher value will mean that the preloader is kept around longer, which may slightly increase memory usage. But as long as the preloader 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 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).

7.6.7. PassengerStartTimeout <seconds>

Introduced in version 4.0.15.

Specifies a timeout for the startup of application processes. If an application process fails to start within the timeout period then it will be forcefully killed with SIGKILL, and the error will be logged.

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

7.6.8. 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 Ruby 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 for 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 has no effect on non-Ruby applications.

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.

7.6.9. 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 Ruby application process. This option only has effect if PassengerConcurrencyModel is thread.

This option has no effect on non-Ruby applications.

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.

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

Caution

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.

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

Caution

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.

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

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

Caution

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.

7.6.13. PassengerStatThrottleRate <integer>

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

  • It checks which the application startup files are present, in order to autodetect the application type.

  • 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 be specified once, in the global server configuration. The default value is 10.

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

   Alias /store /websites/store/public
    <Location /store>
        PassengerBaseURI /store
        PassengerAppRoot /websites/store
    </Location>
    <Directory /websites/store/public>
        Allow from all
        Options -MultiViews
        # Uncomment this if you're on Apache >= 2.4:
        #Require all granted
    </Directory>
</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

   Alias /store /websites/store/public
    <Location /store>
        PassengerBaseURI /store
        PassengerAppRoot /websites/store
    </Location>
    <Directory /websites/store/public>
        Allow from all
        Options -MultiViews
        # Uncomment this if you're on Apache >= 2.4:
        #Require all granted
    </Directory>
</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 and 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.

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

7.7. Connection handling options

7.7.1. PassengerBufferUpload <on|off>

Introduced in version 4.0.26.

When turned on, HTTP client request bodies will be buffered before they are sent the request to the application. This buffering protects the application from slow clients, but also prevents the ability to track upload progress.

If you want to allow your application to track upload progress, it is recommended that you disable upload buffering for specific URIs only. For example:

# Disable upload buffering for /upload_video only.
<Location /upload_video>
    PassengerBufferUpload off
</Location>

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

7.7.2. 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, but its behavior can be tweaked with PassengerResponseBufferHighWatermark.

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

Note

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

7.7.3. PassengerResponseBufferHighWatermark <bytes>

Introduced in version 5.0.0.

As explained in PassengerBufferResponse, Phusion Passenger has two response buffering mechanisms. This option configures the maximum size of the real-time disk-backed response buffering system. If the buffer is full, the application will be blocked until the client has fully read the buffer.

This buffering system has a default size of 128 MB (134217728 bytes). This default value is large enough to prevent most applications from blocking on slow clients, but small enough to prevent broken applications from filling up the hard disk.

You can’t disable real-time disk-backed response buffering, but you can set the buffer size to a small value, which is effectively the same as disabling it.

Most of the time, you won’t need to tweak this value. But there is one good use case where you may want set this option to a low value: if you are streaming a large response, but want to detect client disconnections as soon as possible. If the buffer size is larger than your response size, then Phusion Passenger will read and buffer the response as fast as it can, offloading the application as soon as it can, thereby preventing the application from detecting client disconnects. But if the buffer size is sufficiently small (say, 64 KB), then your application will effectively output response data at the same speed as the client reads it, allowing you to detect client disconnects almost immediately. This is also a down side, because many slow clients blocking your application can result in a denial of service, so use this option with care.

If your application outputs responses larger than 128 MB and you are not interested in detecting client disconnects as soon as possible, then you should raise this value, or set it to 0.

A value of 0 means that the buffer size is unlimited.

This option may only occur once, in the global server configuration. The default value is 134217728 (128 MB).

7.7.4. PassengerErrorOverride <on|off>

Introduced in version 4.0.24.

Decides whether Apache will intercept and handle responses with HTTP status codes of 400 and higher. This directive is useful where you want to have a common look and feel on the error pages seen by the end user. This also allows for included files (via mod_include’s SSI) to get the error code and act accordingly (default behavior would display the error page of the proxied server, turning this on shows the SSI Error message).

This directive does not affect the processing of informational (1xx), normal success (2xx), or redirect (3xx) responses.

By default, all responses are sent as-is from the application or from the Phusion Passenger core. If you turn this option on then Apache will be able to handle such responses using the Apache ErrorDocument option.

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.

7.7.5. PassengerMaxRequestQueueSize <number>

Introduced in version 4.0.15.

When all application processes are already handling their maximum number of concurrent requests, Phusion Passenger will queue all incoming requests. This option specifies the maximum size for that queue. If the queue is already at this specified limit, then Phusion Passenger will immediately send a "503 Service Unavailable" error to any incoming requests.

A value of 0 means that the queue is unbounded.

This article on StackOverflow explains how the request queue works, what it means for the queue to grow or become full, why that is bad, and what you can do about it.

You may combine this option with PassengerErrorOverride and ErrorDocument to set a custom error page whenever the queue is full. In the following example, Apache will serve /error503.html whenever the queue is full:

PassengerErrorOverride on
ErrorDocument 503 /error503.html

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

7.7.6. PassengerStickySessions <on|off>

Introduced in version 4.0.45.

When sticky sessions are enabled, all requests that a client sends will be routed to the same originating application process, whenever possible. When sticky sessions are disabled, requests may be distributed over multiple processes, and may not necessarily be routed to the originating process, in order to balance traffic over multiple CPU cores. Because of this, sticky sessions should only be enabled in specific circumstances.

For applications that store important state inside the process’s own memory — that is, as opposed to storing state in a distributed data store, such as the database or Redis — sticky sessions should be enabled. This is because otherwise, some requests could be routed to a different process, which stores different state data. Because processes don’t share memory with each other, there’s no way for one process to know about the state in another process, and then things can go wrong.

One prominent example is the popular SockJS library, which is capable of emulating WebSockets through long polling. This is implemented through two HTTP endpoints, /SESSION_ID/xhr_stream (a long polling end point which sends data from the server to the client), and /SESSION_ID/xhr_send (a normal POST endpoint which is used for sending data from the client to the server). SockJS correlates the two requests with each other through a session identifier. At the same time, in its default configuration, it stores all known session identifiers in an in-memory data structure. It is therefore important that a particular /SESSION_ID/xhr_send request is sent to the same process where the corresponding /SESSION_ID/xhr_stream request originates from; otherwise, SockJS cannot correlate the two requests, and an error occurs.

So prominent examples where sticky sessions should (or even must) be enabled, include:

  • Applications that use the SockJS library (unless configured with a distributed data store)

  • Applications that use the Socket.io library (unless configured with a distributed data store)

  • Applications that use the faye-websocket gem (unless configured with a distributed data store)

  • Meteor JS applications (because Meteor uses SockJS)

Sticky sessions work through the use of a special cookie, whose name can be customized with PassengerStickySessionsCookieName. Phusion Passenger puts an identifier in this cookie, which tells Phusion Passenger what the originating process is. Next time the client sends a request, Phusion Passenger reads this cookie and uses the value in the cookie to route the request back to the originating process. If the originating process no longer exists (e.g. because it has crashed or restarted) then Phusion Passenger will route the request to some other process, and reset the cookie.

If you have a load balancer in front end of Phusion Passenger + Apache, then you must configure sticky sessions on that load balancer too. Otherwise, the load balancer could route the request to a different server.

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.

7.7.7. PassengerStickySessionsCookieName

Introduced in version 4.0.45.

Sets the name of the sticky sessions cookie.

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

7.8. Compatibility options

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

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

7.9. Logging and debugging options

7.9.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 (crit): Show only critical errors which would cause Phusion Passenger to abort.

  • 1 (error): Also show non-critical errors — errors that do not cause Phusion Passenger to abort.

  • 2 (warn): Also show warnings. These are not errors, and Phusion Passenger continues to operate correctly, but they might be an indication that something is wrong with the system.

  • 3 (notice): Also show important informational messages. These give you a high-level overview of what Phusion Passenger is doing.

  • 4 (info): Also show less important informational messages. These messages show more details about what Phusion Passenger is doing. They’re high-level enough to be readable by users.

  • 5 (debug): Also show the most important debugging information. Reading this information requires some system or programming knowledge, but the information shown is typically high-level enough to be understood by experienced system administrators.

  • 6 (debug2): Show more debugging information. This is typically only useful for developers.

  • 7 (debug3): Show even more debugging information.

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

7.9.2. PassengerLogFile <filename>

Introduced in version 5.0.5.

By default Phusion Passenger log messages are written to the global web server error log. With this option, you can have those messages logged to a different file instead.

This option may only occur once, in the global server configuration.

7.9.3. PassengerFileDescriptorLogFile <filename>

Introduced in version 5.0.5.

Log file descriptor debug tracing messages to the given file.

Phusion Passenger has the ability to log all file descriptors that it opens and closes. These logs are useful to the Phusion Passenger developers for the purpose of analyzing file descriptor leaks.

File descriptor activity is logged as follows:

  • If PassengerFileDescriptorLogFile is not set, then file descriptor activity is logged to the main log file, but only if the log level is 5 (debug) or higher.

  • If PassengerFileDescriptorLogFile is set, then file descriptor activity is logged to the specified file, regardless of the log level.

This option may only occur once, in the global server configuration.

7.9.4. 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), the debugger gem (when on Ruby 1.9) or the byebug gem (when on Ruby 2.0). If you’re using Bundler, you should add this to your Gemfile:

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

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.

7.10. Advanced options

7.10.1. PassengerInstanceRegistryDir <directory>

Introduced in version 5.0.0.

Specifies the directory that Phusion Passenger should use for registering its current instance.

When Phusion Passenger starts up, it creates a temporary directory inside the instance registry directory. This temporary directory is called the instance directory. It contains all sorts of files that are important to that specific running Phusion Passenger instance, such as Unix domain socket files so that all the different Phusion Passenger processes can communicate with each other. Command line tools such as passenger-status use the files in this directory in order to query Phusion Passenger’s status.

It is therefore important that, while Phusion Passenger is working, the instance directory is never removed or tampered with. However, the default path for the instance registry directory is the system’s temporary directory, and some systems may run background jobs that periodically clean this directory. If this happens, and the files inside the instance directory are removed, then it will cause Phusion Passenger to malfunction: Phusion Passenger won’t be able to communicate with its own processes, and you will see all kinds of connection errors in the log files. This malfunction can only be recovered from by restarting Apache. You can prevent such cleaning background jobs from interfering by setting this option to a different directory.

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

The instance directory is automatically removed when Apache shuts down.

This option may be specified once, in the global server configuration. The default value is as follows:

  • If you are on Red Hat and CentOS, and installed Passenger through the RPMs provided by Phusion, then the default value is /var/run/passenger-instreg.

  • Otherwise, the default value is the value of the $TMPDIR environment variable. Or, if $TMPDIR is not set, /tmp.

Note regarding command line tools

Some Phusion Passenger command line administration tools, such as passenger-status, must know what Phusion Passenger’s instance registry directory is in order to function properly. You can pass the directory through the PASSENGER_INSTANCE_REGISTRY_DIR or the TMPDIR environment variable.

For example, if you set PassengerInstanceRegistryDir to /my_temp_dir, then invoke passenger-status after you’ve set the PASSENGER_INSTANCE_REGISTRY_DIR, like this:

export PASSENGER_INSTANCE_REGISTRY_DIR=/my_temp-dir
sudo -E passenger-status

Notes regarding the above example:

  • The -E option tells sudo to preserve environment variables.

  • If Phusion Passenger is installed through an RVM Ruby, then you must use rvmsudo instead of sudo.

7.10.2. PassengerDataBufferDir <directory>

Introduced in version 5.0.0.

By default, Phusion Passenger buffers the following things to disk:

  • Large HTTP client request bodies. This prevents slow HTTP clients from blocking web applications by sending request bodies very slowly. Read PassengerBufferUpload to learn more.

  • Large web application responses. This prevents slow HTTP clients from blocking web applications by reading responses very slowly. This feature is also known as real-time disk-backed response buffering.

By default, such buffers are stored in the directory given by the $TMPDIR environment variable, or (if $TMPDIR is not set) the /tmp directory. This configuration directive allows you to specify a different directory.

Changing this option is especially useful in the following cases:

  • If Apache is not allowed to write to the system’s temporary directory. This is the case on some systems with strict SELinux policies.

  • If the partition that the default directory lives on doesn’t have enough disk space.

If you’ve specified such a directory (as opposed to using Phusion Passenger’s default) then you must ensure that this directory exists.

You can disable client request body buffering by turning PassengerBufferUpload off. It is not possible to turn off real-time disk-backed response buffering.

This option may be specified once, in the global server configuration.

Note This option has no effect when you are using Flying Passenger. Instead, you should configure this by passing the --data-buffer-dir command line option to the Flying Passenger daemon.

7.11. Deprecated or removed options

The following options have been deprecated or removed. Some are still supported for backwards compatibility reasons.

7.11.1. RailsRuby

Deprecated in favor of PassengerRuby.

7.11.2. RailsBaseURI and RackBaseURI

Deprecated in favor of PassengerBaseURI.

7.11.3. RailsUserSwitching

Deprecated in favor of PassengerUserSwitching.

7.11.4. RailsDefaultUser

Deprecated in favor of PassengerDefaultUser.

7.11.5. RailsAllowModRewrite

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

7.11.6. RailsSpawnMethod

Deprecated in favor of PassengerSpawnMethod.

7.11.7. RailsAutoDetect, RackAutoDetect and WsgiAutoDetect

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

7.11.8. RailsAppSpawnerIdleTime

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

7.11.9. 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.11.10. PassengerDebugLogFile

This option has been renamed in version 5.0.5 to PassengerLogFile.

8. Troubleshooting

8.1. Generic troubleshooting tips

One of the first things you should do upon encountering a problem, is to check the global (not the per-vhost) Apache error log file. This is typically located in /var/log/apache2/error_log. You can find out the exact location of the error log by running passenger-config --detect-apache2. This log file contains:

  • Phusion Passenger error messages.

  • Everything that the application writes to STDERR. This typically consists of errors that the application encounters during startup, but not errors that it encounters when it’s handling requests.

If you’re using Ruby on Rails, then you should also check out log/development.log and log/production.log. When an error occurs during request handling, it is typically logged here. This file does not contain errors that Rails encounters during startup.

Finally, you should be aware that Phusion Passenger runs your application under the production environment by default, not development. You can change this using the RailsEnv option.

If neither the logs nor this troubleshooting guide can help you, then please check out our support resources.

8.2. Why does the first request take a long time?

Symptoms

The first request to your application takes more time than usual. Subsequent requests have the normal speed.

Cause

Phusion Passenger starts your application the first time it is accessed, not during web server startup. Some applications can take several seconds to start. If you’re using Ruby on Rails, then needing 10 seconds to start your application is normal. On slow or heavily loaded servers, or in case of large and heavy applications, the startup time may be even longer.

Solution

Use the PassengerPreStart configuration option.

8.3. I get "command not found" when running a Phusion Passenger command through sudo

Symptoms

Phusion Passenger commands can be found as a normal user, but not when run through sudo:

$ passenger-status
...some output, but no "command not found" error...
$ passenger-install-apache2-module
...some output, but no "command not found" error...
$ sudo passenger-status
sudo: passenger-status: command not found
$ sudo passenger-install-apache2-module
sudo: passenger-install-apache2-module: command not found
Cause

The operating system looks up commands using the PATH environment variable. However, sudo resets all environment variables to a default value, dictated by sudo. If Phusion Passenger was installed to a location that is not in the default sudo PATH value, then sudo will not be able to find the Phusion Passenger commands.

In addition, if you installed Phusion Passenger using a Ruby interpreter that was installed through RVM, then you must use rvmsudo instead of sudo. As a rule, when you’re an RVM user, always use rvmsudo instead of sudo.

Solution

Execute the command using its full path. You can use which as a normal user to lookup the full path:

$ which passenger-status
/somewhere/bin/passenger-status

Next, run full path of the command using either sudo or rvmsudo:

$ sudo /somewhere/bin/passenger-status

# -OR, if you're using RVM:-

$ rvmsudo /somewhere/bin/passenger-status
Recommended reading

When using sudo, you will probably run into similar "command not found" issues in the future, with components other than Phusion Passenger. We strongly recommend you to learn about environment variables so that you know what to do in the future.

8.4. OS 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.
Cause

Your MAMP installation seems to be broken. In particular, config_vars.mk is missing.

Solution

Please read this forum topic to learn how to fix this problem. See also this bug report.

8.5. Apache reports a "403 Forbidden" error

See next subsection.

8.6. 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
       Options -MultiViews
       # Uncomment this if you're on Apache >= 2.4:
       #Require all granted
    </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.

8.7. Apache cannot access my app’s files because of SELinux errors

On Red Hat Enterprise Linux and CentOS, Apache is locked down by a security mechanism called SELinux. This security mechanism works on top of normal Unix permissions. In order for Apache to be able to access your app’s files, you must set the proper SELinux labels on your files.

First, ensure that your app does not live in a home directory. It is not possible to allow Apache to read files from your home directory.

Second, give your app’s files the httpd_sys_content_t labels by running the following command:

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

8.8. The application thinks its not on SSL even though it is

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>

8.9. Ruby on Rails-specific troubleshooting

8.9.1. The "About your application’s environment" link does not work

The "About your application’s environment" link only works if the application is started in the development environment. Phusion Passenger starts the application in the production environment by default. Please use RailsEnv to change it.

8.9.2. 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.ru, 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.

8.9.3. The Rails application’s log file is not being written to

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

  • By default, Phusion Passenger runs Rails applications in production mode, so please be sure to check production.log instead of development.log.

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

    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

8.10. Conflicting Apache modules

8.10.1. mod_userdir

mod_userdir is not compatible with Phusion Passenger at the moment.

8.10.2. MultiViews (mod_negotiation)

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

8.10.3. VirtualDocumentRoot

VirtualDocumentRoot is not compatible with Phusion Passenger at the moment.

9. Analysis and system maintenance

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

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

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

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

9.3. Debugging frozen applications

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

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

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

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

10. Tips

10.1. User Switching (security feature)

Phusion Passenger supports automatic user switching: by default, it attempts to run applications as the "right" user, instead of running all applications as the same user.

To better understand the problem, let us consider the situation with PHP. 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’s user switching feature solves this problem. Applications are run as the owner of their "startup file". For Ruby apps, the startup file is config.ru (Rack and Rails >= 3) or config/environment.rb (Rails 1 and 2). For Python apps, the startup file is passenger_wsgi.py. So suppose that config.ru is owned by user joe, then Phusion Passenger will spawn the corresponding application as joe as well. The exact rules are a little bit more complicated, and they’re explained further down in this section.

10.1.1. Requirements

User switching is only enabled when all of the following conditions are met:

  • When not using Flying Passenger (this is probably the case):

    • The PassengerUserSwitching option must be enabled.

    • The web server’s control process must have root privileges. This is the case on most installations.

  • When using Flying Passenger:

    • The Flying Passenger daemon must be run with root privileges.

10.1.2. Effects

When not using Flying Passenger, the following table illustrates the effect for different combinations of the requirements.

PassengerUserSwitching on

PassengerUserSwitching off

Web server has root privileges

User switching enabled.

User switching disabled. Apps are run as PassengerDefaultUser and PassengerDefaultGroup.

Web server has no root privileges

User switching disabled. Apps are run as the web server’s user.

User switching disabled. Apps are run as the web server’s user.

When using Flying Passenger, the effect is as follows:

Daemon run with root privileges

User switching enabled.

Daemon run without root privileges

User switching disabled. Apps are run as the daemon’s user.

When user switching is enabled, the following rules are followed to determine what user an application should be run as. The first matching rule is the rule that will be followed.

  1. If PassengerUser or PassengerGroup are set, then the application will be run as the specified user/group. Thus, these options are a good way to override user switching settings.

  2. If the startup file is owned by root or an unknown user, then the application will run as the user specified by PassengerDefaultUser and PassengerDefaultGroup.

  3. Otherwise, the application is run as the owner of the startup file.

10.1.3. Caveats & troubleshooting

If your application regularly encounters permission errors or fails to find certain files, then this is an indication that your application is started as a user that you did not intent it to be run as. Other symptoms include:

  • The application fails to start because Bundler complains that it cannot find gems. This probably indicates that Bundler does not have read access to the directory that contains Bundler-installed gems.

  • The application fails to start and its error message mentions the path /nonexistent. This probably indicates that your application is started as the nobody user. This is because on many systems, the nobody user’s home directory is /nonexistent.

To check whether it is indeed the case that your application is started as a different user than you intended to, see Finding out what user an application is running as.

The most likely reason why your application is started as nobody is probably because your startup file is owned by root, by nobody or by an unknown user. To fix this, change the owner of the startup file to the owner that you want to run the application as.

Whatever user your application runs as, it must have read access to the application root, and read/write access to the application’s logs directory.

10.1.4. Red Hat and CentOS caveats

Note This information only applies if you installed Passenger through the RPM packages provided by Phusion. If you did not installed Passenger through the RPM packages provided by Phusion, then you can ignore this section.

If you installed Passenger through Phusion’s RPM packages, and you want to disable user switching, then you must also change the location of the instance registry directory.

This is because our RPMs configure the default instance registry directory to /var/run/passenger-instreg, which is only writable by root. If you disable user switching, then the Passenger processes will run as PassengerDefaultUser, which (as long as it’s not root) won’t be able to write to that directory.

Note that any alternative instance registry directory must have the proper SELinux context, allowing the web server to read and write to it. We recommend that you create a directory /var/lib/passenger-instreg and give it the label var_run_t:

sudo mkdir /var/lib/passenger-instreg
sudo chcon -t var_run_t /var/lib/passenger-instreg

Then, in your Apache config file:

PassengerInstanceRegistryDir /var/lib/passenger-instreg

10.1.5. Finding out what user an application is running as

To find our what user an application is started as, first access its URL in your browser so that Phusion Passenger starts the application. For example:

http://www.example.local/

The application will now either successfully start or fail to start. If it fails to start then you will see an error page that tells you what user the application was being started as. If you do not see the error page in the browser then set PassengerFriendlyErrorPages on.

If the application successfully started, then run passenger-status to find the process’s PID:

.---------- General information -----------
Max pool size : 6
Processes     : 1
Requests in top-level queue : 0

.---------- Application groups -----------
/webapps/example.local#default:
  App root: /webapps/example.local
  Requests in queue: 0
  * PID: 16915   Sessions: 0       Processed: 1       Uptime: 2s
    CPU: 0%      Memory  : 9M      Last used: 2s ago

In the above example we see that the PID is 16915. Next, use ps to find out the user that it is running as:

# ps -o pid,user,comm -p 16915
  PID USER    COMM
16915 phusion Passenger RackApp: /webapps/example.local

As you can see, the application in this example is being run as user phusion.

10.2. Copy-on-write memory support (reducing memory consumption of Ruby applications)

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

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

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

10.3. Tuning for Server Sent Events and WebSockets

Phusion Passenger supports Server Sent Events (SSE) and WebSockets out of the box with no configuration, but there are some things you need to know.

Second, for Ruby apps only, you need to insert a configuration snippet inside your config.ru:

if defined?(PhusionPassenger)
  PhusionPassenger.advertised_concurrency_level = 0
end
Note

This snippet tells Passenger that your Ruby app will handle SSE and WebSockets. In response, Passenger will adjust the connection concurrency settings for your app. Without this configuration snippet, SSE and WebSockets still work, but with degraded performance.

This configuration snippet is currently necessary because of the way Passenger is implemented. We are working on improving this mechanism. One day, the above configuration snippet will no longer be necessary. For now, you should include the above configuration snippet for optimal SSE and WebSocket performance.

Finally, you can find Passenger SSE and WebSocket demo apps on the Passenger documentation overview page, under section "Demos".

10.4. Bundler support

Phusion Passenger has automatic support for Bundler. The support consists of loading your application under the environment defined by your Gemfile. In other words, Phusion Passenger loads your application as if bundle exec was used.

The Bundler support 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 an empty 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.

10.4.1. Does Phusion Passenger itself need to be added to the Gemfile?

It is never necessary to add Phusion Passenger to the application’s Gemfile. In case of Phusion Passenger Standalone, it is not necessary to execute the passenger command through bundle exec. The reason for this is because Phusion Passenger automatically loads the Gemfile environment. Most other Ruby application servers do not automatically load the Gemfile environment, which is why they must be added to the Gemfile and be executed with bundle exec.

Even when your application uses any of the Phusion Passenger APIs, you still do not need to add Phusion Passenger to the Gemfile. The only thing you need to do is to put Phusion Passenger API calls inside if blocks that check whether Phusion Passenger is active, by checking whether the PhusionPassenger namespace is defined:

if defined?(PhusionPassenger)
    ...
end

10.5. Installing multiple Ruby on Rails versions

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

gem install rails -v X.X.X

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

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

10.6. Making the application restart after each request

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

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

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

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

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

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

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

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

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

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

10.8. Out-of-Band 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.

  • Phusion Passenger guarantees that no more than 1 process is performing out-of-band work at the same time.

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

  1. Ensure that PassengerMaxPoolSize and PassengerMinInstances are both larger than 1. Out-of-band work only works if there are at least 2 application processes.

  2. Request out-of-band work by outputting the !~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.

  3. 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. This example code doesn’t do anything when the code is not being run in Phusion Passenger, thanks to the if block.

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

# Somewhere during application initialization:
if defined?(PhusionPassenger)
    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
end

For your convenience, Phusion Passenger provides a Rack middleware for out-of-band garbage collection. Add the following to your config.ru. Likewise, this example code doesn’t do anything when the code is not being run in Phusion Passenger, thanks to the if block.

if defined?(PhusionPassenger)
    PhusionPassenger.require_passenger_lib 'rack/out_of_band_gc'

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

It should be noted that, although the application uses the Phusion Passenger API, it is not necessary to add Phusion Passenger to the Gemfile.

References:

10.9. Hooks

Introduced in version 4.0.28.

Phusion Passenger provides a powerful but simple hooking system, which allows you to extend many aspects of Phusion Passenger’s behavior. The hooking system works by executing commands during certain events. Event parameters are passed to the command in the form of environment variables.

You can define hooks by setting the configuration option PassengerCtl hook_<HOOK NAME> <COMMAND TO EXECUTE>.

10.9.1. Example

The hook system is best demonstrated with a simple example. In the following example we will hook into the attached_process event. This event is called whenever Phusion Passenger has successfully spawned an application processes and added it to the process pool. We print the process’s PID and application root.

First, let’s create a script /home/phusion/attached.sh which is to be called during the hook.

#!/bin/sh
echo "Attached process $PASSENGER_PROCESS_PID for app $PASSENGER_APP_ROOT."

Then we make it executable:

chmod +x /home/phusion/attached.sh

And we define the hook in the configuration file:

PassengerCtl hook_attached_process /home/phusion/attached.sh

Now restart the web server and access a web app hosted by Phusion Passenger. You should see our message in the web server error log:

[ 2013-12-10 16:12:21.6456 28934/0x1064cb000 Hooks.h:129 ]: Running attached_process hook script: /home/phusion/attached.sh
Attached process 28303 for app /webapps/foobar.
[ 2013-12-10 16:12:21.6580 28934/0x1064cb000 Hooks.h:161 ]: Hook script /home/phusion/attached.sh (PID 28948) exited with status 0

10.9.2. Environment

A lot of information is passed to hook scripts in the form of environment variables. They are all uppercase and begin with PASSENGER_. Some environment variables are passed to all hook scripts, others are passed depending on the hook.

Here are some of the environment variables which are passed to all hooks, unless documented otherwise:

  • PASSENGER_HOOK_NAME

  • PASSENGER_VERSION

  • PASSENGER_PASSENGER_ROOT

  • PASSENGER_INSTANCE_DIR

  • PASSENGER_INSTANCE_REGISTRY_DIR

10.9.3. Blocking and concurrency

Except when otherwise documented, all hooks block in the background. That is, while your hook command is running, Phusion Passenger can still handle web requests, but the background thread which is running your hook will be blocked and won’t be able to perform any further operations. For example, if you wrote a hook script for the attached_process event, then Phusion Passenger won’t be able to attach further processes until your hook script finishes. You should therefore be careful when writing hook scripts.

If you have a bug in your script and it blocks, then you will be able to see that using the command passenger-status --show=backtraces which prints the backtraces of all threads in the Phusion Passenger HelperAgent. Look for the runSingleHookScript function in the backtrace. The following example shows at line 2 that Phusion Passenger is waiting for the hook script /home/phusion/badscript.sh.

Thread 'Group process spawner: /home/phusion/webapp.test#default' (0x1062d4000):
     in 'bool Passenger::runSingleHookScript(Passenger::HookScriptOptions &, const string &, const vector<pair<string, string> > &)' (Hooks.h:116) -- /home/phusion/badscript.sh
     in 'bool Passenger::runHookScripts(Passenger::HookScriptOptions &)' (Hooks.h:159)
     in 'void Passenger::ApplicationPool2::Group::spawnThreadRealMain(const SpawnerPtr &, const Passenger::ApplicationPool2::Options &, unsigned int)' (Implementation.cpp:878)

Hooks may be called concurrently, because Phusion Passenger sometimes uses multiple background threads. For example, while the attached_process hook is being called, a detached_process hook may be called, perhaps even for the same application. It is your responsibility to ensure that your hook scripts are concurrency-safe, e.g. by employing locks and other concurrency control techniques.

10.9.4. Error handling

If a hook script fails — that is, if it exits with anything other than exit code 0 — then the error handling depends on the hook. Some hooks will abort, other hooks will ignore the error. In all cases, the result of the hook script is printed to the log.

10.9.5. Compatibility

Because hooks are inherently tied to the implementation of Phusion Passenger, there is no guarantee that hooks that currently work will continue to be available in the future versions of Phusion Passenger. The availability of hooks is very much tied to the specific version of Phusion Passenger.

10.9.6. Available hooks

before_watchdog_initialization

Called at the very beginning of Phusion Passenger’s life cycle, during the start of the Watchdog process. The first hook is called before initialization is performed (before the HelperAgent is started). Errors in the hook script cause Phusion Passenger to abort.

after_watchdog_initialization

Like before_watchdog_initialization, but called after initialization of all Phusion Passenger agent processes. Errors in the hook script cause Phusion Passenger to abort.

before_watchdog_shutdown

Called after an exit signal has been noticed (e.g. webserver exit), before the Watchdog starts terminating agents

after_watchdog_shutdown

Called after the Watchdog is done and about to exit

attached_process

Called when Phusion Passenger has successfully spawned an application processes and added it to the process pool. Extra environment variables: PASSENGER_PROCESS_PID, PASSENGER_APP_ROOT. Errors in the hook script are ignored.

detached_process

Called when Phusion Passenger has removed an application process from the process pool. This could happen when:

  • The process has crashed, and Phusion Passenger noticed it.

  • Phusion Passenger has shut down a process because it’s been idle for too long.

  • The administrator configured different resource limits, and Phusion Passenger is starting or shutting down processes in response.

  • Phusion Passenger itself is shutting down.

Extra environment variables: PASSENGER_PROCESS_PID, PASSENGER_APP_ROOT. Errors in the hook script are ignored.

spawn_failed (since 4.0.49)

Called when an application process could not be spawned. This could happen when:

  • The application failing to start. For example: bugs in the application, database problems causing the application to crash, incorrectly installed dependencies.

  • Operating system-level problems, such as running out of memory.

  • The application taking too long to start, and hitting Phusion Passenger’s timeout.

queue_full_error (since 5.0.0 RC 1)

The server rejects new requests (default: HTTP 503) while the request queue is full (https://www.phusionpassenger.com/documentation/Users%20guide%20Nginx.html#passenger_max_request_queue_size). This hook gets called for each rejection.

Extra environment variables:

  • PASSENGER_APP_ROOT: the path to the application that failed to spawn.

  • PASSENGER_APP_GROUP_NAME: the configured app group name.

  • PASSENGER_ERROR_MESSAGE: an error message that describes the problem.

  • PASSENGER_ERROR_ID: a unique ID for this error event. If you search for this ID in the web server error log files, you should be able to find details about the error.

  • PASSENGER_APP_ERROR_MESSAGE: output captured from the application at the time the error occurred.

This hook does not block because it’s always run in an extra background thread. Errors in the hook script are ignored.

max_request_time_reached (since 5.0.2, Enterprise-only)

Called when a max request time limit has been reached. Please note that as soon as this hook has finished executing, the application process will be killed with SIGKILL. So if you want to perform any diagnostics on the process in question (e.g. with strace, gdb, etc), please do not exit your hook script until you’ve obtained all the diagnostics you want.

Extra environment variables:

  • PASSENGER_APP_ID: the PID of the process whose request took too long.

  • PASSENGER_REQUEST_PATH: the path of the request that took took long, e.g. "/photos/edit?id=123".

  • PASSENGER_REQUEST_HOST: the host name of the request that took too long, e.g. "www.example.com". This environment variable is not set if the request doesn’t contain a Host header.

10.10. Flying Passenger

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

Flying Passenger allows one to decouple Phusion Passenger’s life time from the web server’s life time, so that the web server can be independently restarted from Phusion Passenger, and from any of the application processes served by Phusion Passenger.

Normally, Phusion Passenger starts together with the web server, and shuts down together with the web server. The advantages of this default behavior is that it makes Phusion Passenger easy to administer: one only has to deal with the web server process and can expect all relevant processes to be cleaned up after a web server shut down. However this also brings about a disadvantage: every time one restarts the web server (e.g. to make a minor configuration change), Phusion Passenger and all its application processes also get restarted.

This problem is solved by Flying Passenger, which is an advanced mode of operation in Phusion Passenger that allows the web server to be indepedently restarted from Phusion Passenger. When this mode is enabled:

  • One must start Phusion Passenger separately from the web server, namely by starting the Flying Passenger daemon. This daemon must - to an extent - be separately configured and managed from the web server.

  • The web server must be configured to forward requests to the Flying Passenger daemon.

  • You should beware of the caveats and limitations.

10.10.1. Requirements

Before you can use the Flying Passenger feature, you must have Phusion Passenger for Apache properly installed.

10.10.2. Basic usage

Start the Flying Passenger daemon by invoking the flying-passenger command. The only required option is --socket-file. Depending on whether you wish to enable User Switching, you have to start flying-passenger with root privileges or not.

$ sudo flying-passenger --socket-file=/var/run/flying-passenger.sock
I, [2013-06-14T09:10:13.095339 #77179]  INFO -- : Welcome to Flying Passenger 4.1.0
I, [2013-06-14T09:10:13.095339 #77179]  INFO -- : Starting PassengerWatchdog...
I, [2013-06-14T09:10:13.097036 #77179]  INFO -- : PassengerWatchdog started on PID 77181
...
I, [2013-06-14T09:10:13.129017 #77179]  INFO -- : PassengerWatchdog initialized properly
I, [2013-06-14T09:10:13.129127 #77179]  INFO -- : Flying Passenger up and listening on /var/run/flying-passenger.sock!

Now configure the web server to make use of the Flying Passenger daemon, by setting the PassengerFlyWith option to the socket filename:

PassengerFlyWith /var/run/flying-passenger.sock

After (re)starting Apache, Apache + Flying Passenger is fully operational:

$ sudo service apache2 restart

Flying Passenger is fully operational:

You can test it by adding a virtual host for a web app:

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

Verify that it works by making an HTTP request to it:

$ curl http://www.foo.local/

Now let’s verify that restarting the web server does not restart the just-spawned application process. Run passenger-status to obtain the PID of the application process:

$ sudo passenger-status
Version: 4.1.0
Date   : 2013-06-14 09:21:51 -0400
.---------- General information -----------
Max pool size : 6
Processes     : 1
Requests in top-level queue : 0

.---------- Application groups -----------
/webapps/foo#default:
  App root: /webapps/foo
  Requests in queue: 0
  * PID: 77283   Sessions: 0       Processed: 1       Uptime: 2s
    CPU: 1%      Memory  : 8M      Last used: 2s ago

As you can see, the PID of the application process is 77283. Now let’s see what happens if we restart the web server:

$ sudo service apache2 restart
$ sudo passenger-status

The application process should remain there, unchanged:

$ sudo passenger-status
Version: 4.1.0
Date   : 2013-06-14 09:21:51 -0400
.---------- General information -----------
Max pool size : 6
Processes     : 1
Requests in top-level queue : 0

.---------- Application groups -----------
/webapps/foo#default:
  App root: /webapps/foo
  Requests in queue: 0
  * PID: 77283   Sessions: 0       Processed: 1       Uptime: 18s
    CPU: 1%      Memory  : 8M      Last used: 18s ago

10.10.3. Configuring Flying Passenger

Flying Passenger gets some configuration from the web server, but not all. In particular, most web server directives that are only valid in the global context, e.g. PassengerLogLevel, have no effect when using Flying Passenger. Instead, you are supposed to pass these configuration directives through command line options to the Flying Passenger daemon. Configuration directives that have no effect on Flying Passenger are documented as such. You can assume that configuration directives that are not documented as such, work fine on Flying Passenger.

For example, to achieve the same effect as setting PassengerLogLevel to 2, run the Flying Passenger daemon as follows:

$ sudo flying-passenger --socket-file=/var/run/flying-passenger.sock --log-level=2

Currently, not all configuration directives have a Flying Passenger equivalent. Run the following command to see an overview of available options:

$ flying-passenger --help

10.10.4. Managing the Flying Passenger daemon

The Flying Passenger daemon runs in the foreground by default. This is undesirable on server environments. You can make it go into the background by passing --daemonize, --log-file and --pid-file:

$ sudo flying-passenger --socket-file=/var/run/flying-passenger.sock \
    --daemonize --log-file=/var/log/flying-passenger.log \
    --pid-file=/var/run/flying-passenger.pid

You can shut down a Flying Passenger daemon by sending SIGINT or SIGTERM to it:

$ kill `cat /var/run/flying-passenger.pid`

We recommend using daemontools or runit for managing the Flying Passenger daemon. These tools will allow automatically starting the Flying Passenger daemon at boot, and will automatically restart the daemon if it crashes. You can create and enable a daemontools/runit service as folows:

$ sudo mkdir /etc/service/flying-passenger
$ sudo nano /etc/service/flying-passenger/run
#!/bin/sh
exec /path-to/flying-passenger \
    --socket-file=/var/run/flying-passenger.sock \
    --log-file=/var/log/flying-passenger.log \
    --pid-file=/var/run/flying-passenger.pid

Immediately after creating the run file, daemontools/runit automatically runs it to start the daemon. Note that the location (/etc/service) depends on the OS or Linux distros. Sometimes it’s /service. Also note that we start the Flying Passenger daemon without --daemonize.

To shut down a daemontools/runit-managed daemon, you need to use svc -d /etc/service/flying-passenger (daemontools) or sv stop /etc/service/flying-passenger (runit) instead of sending a signal to the process.

10.10.5. Using Flying Passenger with MRI 1.8 or JRuby

Using Flying Passenger in combination with MRI Ruby 1.8 or with JRuby requires special attention. This is because the Flying Passenger daemon is written in Ruby, and requires proper Process.spawn support, which neither MRI 1.8 nor JRuby support.

It is however possible to use Flying Passenger with MRI Ruby 1.8 and JRuby. You can’t run the Flying Passenger daemon in MRI 1.8 or JRuby, but you can still run the web applications - hosted under Flying Passenger - in MRI 1.8 or JRuby.

First, edit your web server configuration file and specify a Ruby interpreter for your web applications. For example:

# Connect to the Flying Passenger daemon on the following socket
PassengerFlyWith /var/run/flying-passenger.sock
...

<VirtualHost *:80>
    ServerName www.foo.com
    DocumentRoot /webapps/foo/public
    # Use JRuby for this web application
    PassengerRuby /opt/jruby/bin/jruby
</VirtualHost>

Then you need to install a Ruby 1.9-compatible Ruby interpreter with POSIX spawn support, alongside JRuby/MRI 1.8. Ruby interpreters which can be used for running the Flying Passenger daemon include:

  • MRI Ruby >= 1.9.

  • Rubinius.

The following example demonstrates how you can install MRI Ruby 1.9 in parallel with your MRI Ruby 1.8 or JRuby installation.

Example for Debian/Ubuntu users:

# Install Ruby 1.9
sudo apt-get install ruby1.9.3
# Run the Flying Passenger daemon in Ruby 1.9
ruby1.9 -S flying-passenger --socket-file=/var/run/flying-passenger.sock

Example for RVM users:

# Install Ruby 1.9
rvm install 1.9.3
# Run the Flying Passenger daemon in Ruby 1.9
$ rvm-exec 1.9.3 ruby -S flying-passenger --socket-file=/var/run/flying-passenger.sock

The Flying Passenger daemon will now be run on Ruby 1.9, while the web application www.foo.com will be run on JRuby.

10.10.6. Caveats and limitations

Beware of the following caveats and limitations when using Flying Passenger:

  • The Phusion Passenger module that is loaded into Apache, must be of the same version as the Flying Passenger daemon. Failing to meet this requirement may result in cryptic errors, or may result in certain features not working, until you’ve fixed the situation. When upgrading Phusion Passenger, you must restart both Apache and the Flying Passenger daemon.

  • The PassengerRoot directive has no effect. When using Flying Passenger, you are not supposed to set PassengerRoot.

  • The Flying Passenger daemon is written in Ruby. It requires a Ruby interpreter with proper Process#spawn support. At the time of writing, all Ruby interpreters in existance satisfy this requirement, except for MRI Ruby 1.8 and JRuby. See Using Flying Passenger with MRI 1.8 or JRuby for more information.

  • When you add a new application to the web server configuration, Flying Passenger will automatically pick up the application’s settings and spawn this new application upon the first request to it. However it is not capable of automatically starting the new app before a request has been sent to it (i.e. PassengerPreStart-like behavior is not available in this case). As a workaround, you can send an HTTP request to your application after starting the daemon, which forces it to spawn application processes.

  • When you remove an application from the web server configuration, Flying Passenger will not detect the removal and will not shut down the associated application processes. Killing the application processes will also not help, because Flying Passenger will restart them per the (now-removed, but still in the Flying Passenger daemon’s memory) PassengerMinInstances settings. At the moment, there are two ways to get rid of those processes:

    • Before removing the application from the web server configuration, explicitly set its PassengerMinInstances to 0. Next, send a request to it, which will cause the Flying Passenger daemon to take over the new PassengerMinInstances 0 option. You can then proceed with removing the application from the web server configuration, and restarting the web server. Finally, kill the PIDs associated to those application processes and remove the application configuration.

    • Restart the Flying Passenger daemon.

10.11. X-Sendfile support

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

10.12. Upload progress

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

11. Under the hood

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

11.1. Page caching support

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

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

  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.

11.2. Phusion Passenger and its relationship with Ruby

11.2.1. How Ruby is used

Phusion Passenger’s core is written in C++ for performance and memory efficiency. It supports web applications written in any language. Phusion Passenger requires Ruby, its usage of Ruby is minimal in order to maximize performance and to minimize memory usage.

  • Phusion Passenger’s installer, build system and administration tools are written in Ruby.

  • Certain internally used tools, such as the crash handler (which generates a backtrace in case Phusion Passenger crash) and the prespawn script (used to implement PassengerPreStart) are written in Ruby as well.

  • Ruby web application support is implemented in Ruby.

  • If you use Flying Passenger, then the Flying Passenger daemon is written in Ruby. The daemon is a small (less than 500 lines of code) and offloads most tasks to the C++ core.

  • If you use Phusion Passenger Standalone, then the frontend (the passenger command) is written in Ruby. The frontend is small (less than 1500 lines of code) and offloads most tasks to the C++ core.

Other than the aforementioned aspects, Phusion Passenger does not use Ruby during normal operation. For example, if you run Python WSGI web applications on Phusion Passenger, then there will be (almost) no Ruby code running on the system.

11.2.2. When the system has multiple Ruby interpreters

Phusion Passenger may be installed with any Ruby interpreter. Once installed, you can run Phusion Passenger’s Ruby parts under any Ruby interpreter you want, even if that Ruby interpreter was not the one you originally installed Phusion Passenger with.

The reason for this is that Phusion Passenger does not dynamically link to Ruby: Phusion Passenger uses Ruby entirely out-of-process. Thus you can switch to any Ruby interpreter you want during runtime, without recompiling Phusion Passenger, and without worrying about what Ruby you used to install Phusion Passenger.

Phusion Passenger is also capable of running Ruby web applications under any Ruby interpreter you want. So it is not important which Ruby you use to install Phusion Passenger: it will work regardless. Please refer to the documentation for the PassengerRuby directive to learn how run different web applications under different Ruby interpreters.

Caveat: RVM and RVM gemsets

There is however one caveat if you happen to be using RVM or RVM gemsets. When you gem install Phusion Passenger using RVM, then RVM will install Phusion Passenger into the currently active RVM Ruby and gemset. This means that Phusion Passenger commands - such as passenger, passenger-install-xxx-module and passenger-status - are available in that same RVM Ruby and gemset only. When you switch Ruby interpreter, or when you switch gemset, the Phusion Passenger commands will no longer be available, and you will get a command not found error. Here’s an example which demonstrates the problem.

"Command not found" problem demonstration
## Install Phusion Passenger (open source edition) using Ruby 1.9.3
## and the 'business' gemset
$ rvm use 1.9.3
Using /home/phusion/.rvm/gems/ruby-1.9.3-p429
$ rvm gemset create business
$ rvm gemset use business
Using ruby-1.9.3-p429 with gemset business
$ curl -O https://s3.amazonaws.com/phusion-passenger/releases/gem_bootstrap.sh
$ eval "`sh gem_bootstrap.sh`"
$ gem install passenger

## Verify that passenger works
$ passenger --version
Phusion Passenger version 4.0.14

## Switch to a different RVM gemset. You will get a `command not found`
$ rvm gemset use default
Using ruby-1.9.3-p429 with gemset default
$ passenger --version
bash: passenger: command not found

## Switch to a different Ruby interpreter. You will also get
## a `command not found`
$ rvm use 2.0.0
Using /home/phusion/.rvm/gems/ruby-2.0.0-p195
$ passenger --version
bash: passenger: command not found

## Switch back to the Ruby and gemset that you installed Phusion
## Passenger with, and verify that it works again
$ rvm use 1.9.3
Using /home/phusion/.rvm/gems/ruby-2.0.0-p195
$ rvm gemset use business
Using ruby-1.9.3-p429 with gemset business
$ passenger --version
Phusion Passenger version 4.0.14
Solutions

There are several ways to solve this problem:

  1. Permanently add Phusion Passenger’s command directory to your PATH, so that your shell can always find them even when you switch RVM Ruby or gemset. If you don’t know what PATH means, please read About environment variables first.

    The drawback is that you have to redo this every time you upgrade Phusion Passenger, because the Phusion Passenger directory filename is dependent on the version number.

    First, identify the location of the Phusion Passenger command directory, like this:

    $ echo `passenger-config --root`/bin
    /home/phusion/.rvm/gems/ruby-1.9.3-p429/gems/passenger-4.0.15/bin

    Next, add the directory that you’ve found to your current shell’s PATH:

    $ export PATH=/home/phusion/.rvm/gems/ruby-1.9.3-p429/gems/passenger-4.0.15/bin:$PATH

    Finally, make the change permanent by appending the above command to your bash startup file:

    $ echo 'export PATH=/home/phusion/.rvm/gems/ruby-1.9.3-p429/gems/passenger-4.0.15/bin:$PATH' >> ~/.bashrc
  2. Switch back to the RVM Ruby and gemset that you installed Phusion Passenger with, before running any Phusion Passenger command.

  3. Prepend any Phusion Passenger command with rvm-exec RUBY_NAME@GEMSET_NAME ruby -S. If the relevant Phusion Passenger command also needs root privileges, then prepend rvmsudo before that. For example:

    rvm-exec 1.9.3@business ruby -S passenger --version
    rvmsudo rvm-exec 1.9.3@business ruby -S passenger-install-apache2-module

11.3. Static assets serving

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

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

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

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

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

13. Appendix B: Terminology

13.1. Application root

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

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

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

13.2. Idle process

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

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

14. Appendix C: Spawning methods explained

At its core, Phusion Passenger is an HTTP proxy and process manager. It spawns application processes and forwards incoming HTTP request to one of them.

While this may sound simple, there’s not just one way to spawn application 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.

14.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 processes, and each process contains a full copy of the Rails application and the Rails framework in memory.

14.2. The smart spawning method

Note Smart spawning is only supported for Ruby applications. It’s not supported for other languages.

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

Application processes and direct spawning
Figure: Application processes and direct spawning. Each process has its own private copy of the application code and Rails framework code.

It is possible to make the different 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.

The smart spawn method is similar to Unicorn’s preload_app true feature.

14.2.1. How it works

When the smart spawn method is being used, Phusion Passenger will first create a so-called preloader process. This process loads the entire Rails application along with the Rails framework, by evaluating config.ru. Then, whenever Phusion Passenger needs a new application process, it will instruct the preloader to create one. The preloader then then spawns a child process, which is an exact virtual copy of itself. This child process therefore already has the application code and the Rails framework code in memory.

Creating a process like this is very fast, about 10 times faster than loading the Rails application/framework from scratch. On top of that, the OS also applies an optimization called copy-on-write. This means that all memory that the child process hasn’t modified, is shared with the parent process.

images/smart_spawning.png
Figure: Application processes and the smart spawn method. All processes, as well as the preloader, share the same application code and Rails framework code.

However, Ruby can only leverage this copy-on-write optimization if its garbage collector is friendly. This is only the case starting from Ruby 2.0.0. Earlier versions cannot leverage copy-on-write optimizations.

Note that preloader processes have an idle timeout just like application processes. If a preloader hasn’t been instructed to do anything for a while, it will be shutdown in order to conserve memory. This idle timeout is configurable.

14.2.2. Summary of benefits

Suppose that Phusion Passenger needs a process for an application that uses Rails 4.1.0.

If the smart spawning method is used, and a preloader for this application is already running, then process creation time is about 10 times faster than direct spawning. This process will also share application and Rails framework code memory with the preloader, as well as with other processes that have been spawned by the same preloader.

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 caveats. But if you understand the caveats you can easily reap the benefits of smart spawning.

14.3. Smart spawning caveat #1: unintentional file descriptor sharing

Because application processes are created by forking from a preloader process, it will share all file descriptors that are opened by the preloader process. (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 application 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 application 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 config.ru:

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 application process, which is why you normally do not encounter any database issues when using smart spawning mode.

14.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 preloader to have a socket connection (file descriptor) to the Memcached server, as shown in the following figure:

+--------------------+
| Preloader          |-----------[Memcached server]
+--------------------+

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

+--------------------+
| Preloader          |------+----[Memcached server]
+--------------------+      |
                            |
+--------------------+      |
| App 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 Preloader and App process 1 both share the same connection to Memcached.

Now supposed that your site gets a sudden large surge of traffic, and Phusion Passenger needs to spawn another process. It does so by forking Preloader. The result is now as follows:

+--------------------+
| Preloader          |------+----[Memcached server]
+--------------------+      |
                            |
+--------------------+      |
| App process 1      |-----/|
+--------------------+      |
                            |
+--------------------+      |
| App process 2      |-----/
+--------------------+

As you can see, App process 1 and App 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 App process 1, and Jane’s request is handled by App process 2. Both application 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 App process 1 having only sent "FE", a context switch occurs, and App process 2 starts sending a "FETCH" command to Memcached as well. If App 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:

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

App 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

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

14.4. Smart spawning caveat #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 application process. You need to revive them when a new 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

15. Appendix D: About environment variables

Environment variables are named values that affect how the system works. For example they tell the system where to look for commands (the PATH variable) or where to look for libraries (LD_LIBRARY_PATH). Their names are often in all-uppercase. Sometimes people refer to an environment variable with a dollar sign $ in front, but that’s the same thing: when people say "the $PATH environment variable" they mean "the PATH environment variable". This is because the dollar sign $ is a shell syntax for refering to an environment variable, as you will learn later.

Environment variables are set on a per-process basis, but they are inherited by child processes. This means that if you set environment variables in process A, another already running process B will not see these new environment variables. But if A spawns a child process C, then C will have all environment variables that A had. If you once again change the environment variables in A, then C will not see the changes.

The per-process nature of environment variables some implications. When you set environment variables in your bashrc or other bash startup files…

  • …only newly spawned bash shells see them.

  • …the web server usually does not see them, because the web server tends to be started from init scripts, not from bash.

  • …cron jobs do not see them, because cron jobs' environment variables are entirely dictated by their crontabs.

Note Because this chapter is meant for beginners, it assumes that the reader uses the bash shell. This chapter does not describe instructions for zsh, csh or other shells. We assume that users of other shells are familiar with the Bourne shell syntax, and know how to apply the instructions in this chapter in their shells' native syntaxes.

15.1. Working with environment variables

You can see all environment variables in your shell by running the following command:

env

You can set an evironment variable with the syntax export <NAME>=<VALUE>. For example, to set the APXS2 variable to the value /usr/sbin/apxs2:

export APXS2=/usr/sbin/apxs2

Any process that you run from your shell from that point on will have said environment variable:

export APXS2=/usr/sbin/apxs2
ruby -e 'p ENV["APXS2"]'
# => "/usr/sbin/apxs2"
Note
The "export" keyword is important

You must set the export keyword. If you omit the export keyword then the environment variable will not be visible to other processes:

APXS2=/usr/sbin/apxs2
ruby -e 'p ENV["APXS2"]'
# => nil

You can reference an environment variable in your shell by typing the $ sign followed by the environment variable’s name. For example, to see the value of the PATH variable:

echo $PATH

You can also use this trick to extend the value of an environment variable:

export PATH=/usr/bin

# Prepends '/opt/local/bin', so that it becomes /opt/local/bin:/usr/bin
export PATH=/opt/local/bin:$PATH
# Appends '/usr/local/bin', so that it becomes /opt/local/bin:/usr/bin:/usr/local/bin
export PATH=$PATH:/usr/local/bin

15.2. The PATH environment variable

The PATH environment variable dictates where the system looks for command. It is a colon-separated list of directories. If you get a "command not found" error while you know that the command is installed, then setting PATH will help. For example suppose that the command frobnicator is in /opt/local/bin:

user@localhost bash$ frobnicator
bash: frobnicator: command not found

We verify that /opt/local/bin is not in PATH:

user@localhost bash$ echo $PATH
/bin:/usr/bin:/usr/local/bin

We can run frobnicator through it’s full path…

user@localhost bash$ /opt/local/bin/frobnicator
# => success!

…or we can add /opt/local/bin to PATH.

user@localhost bash$ export PATH=$PATH:/opt/local/bin
user@localhost bash$ frobnicator
# => success!

15.2.1. Adding Phusion Passenger’s administration tools to PATH

If you get a "command not found" error when invoking one of the Phusion Passenger administration tools (e.g. passenger-status or passenger-memory-stats then that means the tools are not in PATH, so you need to add them.

  • If you installed Phusion Passenger with RubyGems, then the tools are in your RubyGems executable path. You can view the gem path using the command gem env:

    $ gem env
    RubyGems Environment:
      - RUBYGEMS VERSION: 1.8.15
      - RUBY VERSION: 1.8.7 (2011-12-28 patchlevel 357) [i686-darwin10.8.0]
      - INSTALLATION DIRECTORY: /opt/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8
      - RUBY EXECUTABLE: /opt/ruby-enterprise-1.8.7-2010.01/bin/ruby
      - EXECUTABLE DIRECTORY: /opt/ruby-enterprise-1.8.7-2010.01/bin    <--------- !!
      - RUBYGEMS PLATFORMS:
        - ruby
        - x86-darwin-10
      - GEM PATHS:
         - /opt/ruby-enterprise-1.8.7-2010.01/lib/ruby/gems/1.8
         - /Users/hongli/.gem/ruby/1.8
      - GEM CONFIGURATION:
         - :update_sources => true
         - :verbose => true
         - :benchmark => false
         - :backtrace => false
         - :bulk_threshold => 1000
         - "gem" => "--no-ri --no-rdoc"
      - REMOTE SOURCES:
         - http://rubygems.org/

    As you can see, the RubyGems executable path in the example happens to be /opt/ruby-enterprise-1.8.7-2010.01/bin. So that directory must be added to PATH.

  • If you installed Phusion Passenger using the tarball, then the tools are in the bin subdirectory of the Phusion Passenger tarball directory that you extracted. For example, if you extracted passenger-4.9.0.tar.gz inside /opt, then the tools are located in /opt/passenger-4.0.9/bin. In that case, you need to add /opt/passenger-4.0.9/bin to your PATH.

  • If you installed Phusion Passenger using native OS packages, then some Phusion Passenger administration tools are in /usr/bin, while others are in /usr/sbin. If you are not logged in as root, then /usr/sbin may not be in PATH, which would explain why you get a "command not found" when trying to invoke some of the tools. You should /usr/sbin to PATH.

  • If you are unsure where your Phusion Passenger directory is then you can use the find command to look them up. Go to the root directory and invoke find with sudo:

    $ cd /
    $ sudo find . -name passenger-status
    /usr/local/passenger/bin/passenger-status

    In this example, the administration tools happen to be in /usr/local/passenger/bin, so you must add that to PATH.

Note You may still get a "command not found" when invoking the tools through sudo, even after you’ve added the relevant directory to PATH. Please read Environment variables and sudo to learn more.

15.3. Making environment variables permanent

When you exit your shell, the evironment variable changes are lost. There is no standard method to set environment variables system-wide, so you have to set them in different configuration files for different services.

15.3.1. bash

To make environment variables permanent for future bash sessions for the current user, add them to your ~/.bashrc:

echo 'export FOO=bar' >> ~/.bashrc
echo 'export PATH=/usr/local/bin:$PATH' >> ~/.bashrc

To make them permanent for future bash sessions for all users, add them to /etc/bashrc.

Note Depending on the system, the bashrc file may have a different filename. On Debian and Ubuntu, it’s /etc/bash.bashrc. NOTE: Make sure your ~/.bashrc is actually included by your ~/.profile, which might not be the case if you created the user with useradd instead of adduser for example

15.3.2. Apache

Note This subsection describes how to set environment variables on Apache itself, not on apps served through Phusion Passenger for Apache. The environment variables you set here will be passed to all apps, but you cannot customize them on a per-app basis. See also Setting environment variables on Phusion Passenger-served apps.

On Debian and Ubuntu, with an Apache installed through apt, Apache environment variables are defined in the file /etc/apache2/envvars. This is a shell script so environment variables must be specified with the shell syntax.

On Red Hat, Fedora, CentOS and ScientificLinux, with an Apache installed through YUM, Apache environment variables are defined in /etc/sysconfig/httpd.

On OS X they are defined in /System/Library/LaunchDaemons/org.apache.httpd.plist, as explained here on Stack Overflow.

On other systems, or if you did not install Apache through the system’s package manager, the configuration file for environment variables is specific to the vendor that supplied Apache. There may not even be such a configuration file. You should contact the vendor for support.

15.3.3. Nginx

Note This subsection describes how to set environment variables on Nginx itself, not on apps served through Phusion Passenger for Nginx. The environment variables you set here will be passed to all apps, but you cannot customize them on a per-app basis. See also Setting environment variables on Phusion Passenger-served apps.

If you installed Nginx through the Debian or Ubuntu packages, then you can define environment variables in /etc/default/nginx. This is a shell script so you must use the export FOO=bar syntax.

Otherwise, environment variables are best set through the script which starts Nginx. For example, if you installed Nginx from source and you used the Nginx init script described in the Phusion Passenger Users Guide, Nginx version, then you should edit that script to define the environment variables. Those init scripts are regular shell scripts, so use the export FOO=bar syntax. Just make sure your set your environment variables before the script starts Nginx.

Note Setting environment variables on Nginx has no effect on the Flying Passenger daemon because the daemon is started seperately. You should set the environment variables in the shell right before starting the daemon.

15.3.4. cron

To make environment variables permanent for cron jobs, add those variables to the relevant crontab. But note that inside crontabs you cannot refer to existing environment variables with the $ syntax because crontabs are not shell scripts. You have to specify the entire value.

What to put in "crontab -e"
# Environment variable definitions
FOO=bar
APXS2=/usr/sbin/apxs2

# **WRONG!** You cannot refer to existing variables with the `$` syntax!
PATH=/usr/bin:$PATH
# **WRONG!** You cannot use the 'export' keyword!
export PATH=/usr/bin:/usr/local/bin
# Correct:
PATH=/usr/bin:/usr/local/bin

# Jobs:
# m h  dom mon dow   command
  * *  *   *   *     frobnicator

15.3.5. Phusion Passenger-served apps

You can pass environment variables to Phusion Passenger-served apps through various methods:

  • When running Apache, use the PassEnv and SetEnv directives of mod_env. This is supported starting from Phusion Passenger 4.0.

  • When running Nginx, use the passenger_env_var directive.

  • Through your bashrc. Starting from version 4.0, Phusion Passenger 4.0 spawns applications through bash and inherit all bash environment variables. Phusion Passenger Standalone tends to be started from the shell and thus inherits all environment variables set by the shell.

  • Through Apache and Nginx, as described earlier in this chapter. Any environment variables that you set on Apache and Nginx itself are inherited by Phusion Passenger, and thus by Phusion Passenger-served apps as well.

  • Through the application itself. Most programming languages provide APIs for setting environment variables. For example in Ruby you can write:

    ENV['FOO'] = 'bar'

    In Python you can write:

    import os
    os.environ['FOO'] = 'bar'

15.4. Environment variables and sudo

Note RVM users should always use the rvmsudo command instead of sudo. However all information in this section apply to rvmsudo as well.

The sudo command resets all environment variables before running the specified command, for security reasons. So if you set environment variables before running sudo passenger-install-xxx-module, sudo passenger-status or any other commands, then the environment variables are not correctly passed to the command. You can solve this by running sudo with -E (preserve environment variables):

user@localhost bash$ export APXS2=/usr/sbin/apxs2
user@localhost bash$ sudo -E passenger-install-apache2-module

Alternatively, you can obtain a root prompt with sudo first, and then set the environment variables, before running any further commands:

user@localhost bash$ sudo -s
Password: ...
root@localhost bash# export APXS2=/usr/sbin/apxs2
root@localhost bash# passenger-install-apache2-module

Note that for security reasons, sudo always resets the PATH environment variable, even if you pass -E! You can get around this problem by obtaining a root prompt first, and then set the environment variables:

user@localhost bash$ sudo -s
Password: ...
root@localhost bash# export PATH=$PATH:/opt/myruby/bin
root@localhost bash# passenger-install-apache2-module