Phusion Passenger users guide

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

Phusion Passenger has been tested on:

Other operating systems have not been tested, but Phusion Passenger will probably work fine on them. Please report a bug or join our discussion list if it doesn’t.

There are two ways to install Phusion Passenger:

In our opinion, installing the gem or the native package is easiest.

Phusion Passenger provides an easy-to-use installer for installing the Phusion Passenger Apache module (mod_passenger).

If your system has multiple Apache installations (this is likely the case on MacOS X), then you will need to tell the Phusion Passenger installer which one to use. If you only have one Apache installation (the case on most Linux systems), then you can skip this section because Phusion Passenger will automatically detect it.

Every Apache installation has its own apxs program. You will need to tell Phusion Passenger the location of this program, by specifying the APXS2 environment variable. Suppose that you want to use the Apache installation in /opt/apache2. Then, assuming that the corresponding apxs program is located /opt/apache2/bin/apxs, type:

If your system has multiple Ruby installations (this is likely the case on MacOS X), then you will need to tell the Phusion Passenger installer which one to use. If you only have one Ruby installation (the case on most Linux systems), then you can skip this section because Phusion Passenger will automatically detect it.

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

and you want to use the latter, then type:

Please install the gem and then run the Phusion Passenger installer, by typing the following commands:

Please follow the instructions given by the installer.

John Leach from Brightbox has kindly provided an Ubuntu Hardy package for Phusion Passenger. The package is available from the Brightbox repository.

Please install the native Linux package, e.g.:

Extract the tarball to whatever location you prefer. The Phusion Passenger files are to reside in that location permanently. For example, if you would like Phusion Passenger to reside in /opt/passenger-x.x.x:

Next, run the included installer:

Please follow the instructions given by the installer.

Ben Ruebenstein has written an excellent tutorial on installing Phusion Passenger on OS X.

Ben Hughes has written an article on installing Phusion Passenger on Ubuntu.

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

Add a virtual host entry to your Apache configuration file. The virtual host’s document root must point to your Ruby on Rails application’s public folder. For example:

Then restart Apache. The application has now been deployed.

Suppose that you already have a virtual host:

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

To do this, make a symlink from your Ruby on Rails application’s public folder to a directory in the document root. For example:

Next, add a RailsBaseURI option to the virtual host configuration:

Then restart Apache. The application has now been deployed.

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

There are two ways to restart the application:

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

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

See Capistrano recipe.

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:

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

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

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

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

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

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

Add a virtual host entry to your Apache configuration file. The virtual host’s document root must point to your Rack application’s public folder. For example:

Then restart Apache. The application has now been deployed.

Suppose that you already have a virtual host:

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

To do this, make a symlink from your Rack application’s public folder to a directory in the document root. For example:

Next, add a RackBaseURI option to the virtual host configuration:

Then restart Apache. The application has now been deployed.

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:

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

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

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

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:

The location to the Phusion Passenger root directory. This configuration option is essential to Phusion Passenger. The correct value is given by the installer, and should usually not be changed manually.

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

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:

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

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

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

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 each place, it may be specified at most once.

Example:

Turns the use of global queuing on or off.

This option may occur in the following places:

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

This feature is sponsored by 37signals.

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

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

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

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

For example suppose that:

The situation looks like this:

Each process is currently serving short-running requests.

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

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

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

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

Turning global queuing off will yield a minor performance improvement (about 5%, depending on how fast/slow your web application is), which is why it’s off by default.

Whether to enable user switching support.

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

Passenger enables user switching support by default. This configuration option allows one to specify which user Rails/Rack 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.

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

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:

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:

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

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:

This way, Phusion Passenger will not interfere with Wordpress.

PassengerEnabled may occur in the following places:

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

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

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

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

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

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

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

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.

The maximum number of Ruby on Rails or Rack application instances that may be simultaneously active. A larger number results in higher memory usage, but improved ability to handle concurrent HTTP clients.

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

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

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

The maximum number of application instances that may be simultaneously active 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 instances 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.

The maximum number of seconds that an application instance may be idle. That is, if an application instance 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 instances will not be shutdown unless it’s really necessary, i.e. when Phusion Passenger is out of worker processes for a given application and one of the inactive application instances needs to make place for another application instance. 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.

The maximum number of requests an application instance will process. After serving that many requests, the application instance will be shut down and Phusion Passenger will restart it. A value of 0 means that there is no maximum: an application instance 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 each place, it may be specified at most once. The default value is 0.

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

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

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

This option may occur in the following places:

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

Whether Phusion Passenger should automatically detect whether a virtual host’s document root is a Ruby on Rails application. The default is on.

This option may occur in the global server configuration or in a virtual host configuration block.

For example, consider the following configuration:

If one goes to http://www.mycook.com/, the visitor will see the contents of the /webapps/mycook/public folder, instead of the output of the Ruby on Rails application.

It is possible to explicitly specify that the host is a Ruby on Rails application by using the RailsBaseURI configuration option:

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

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

This option may occur in the following places:

This option allows one to specify the default RAILS_ENV value.

This option may occur in the following places:

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

Internally, Phusion Passenger spawns multiple Ruby on Rails 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:

This option may occur in the following places:

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

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

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

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

This option may only occur in the global server configuration, and may occur at most once. The default value is 1800 (30 minutes).

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

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

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

This option may only occur in the global server configuration, and may occur at most once. The default value is 600 (10 minutes).

Whether Phusion Passenger should automatically detect whether a virtual host’s document root is a Rack application. The default is on.

This option may occur in the global server configuration or in a virtual host configuration block.

For example, consider the following configuration:

If one goes to http://www.rackapp.com/, the visitor will see the contents of the /webapps/my_rack_app/public folder, instead of the output of the Rack application.

It is possible to explicitly specify that the host is a Rack application by using the RackBaseURI configuration option:

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

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

This option may occur in the following places:

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

This option may occur in the following places:

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

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

Deprecated in favor of PassengerRuby.

Deprecated in favor of PassengerUserSwitching.

Deprecated in favor of PassengerDefaultUser.

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

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

See also this bug report.

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

Here’s how you can install the development headers:

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

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

Please try setting RailsSpawnMethod to conservative.

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

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

See next subsection.

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:

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

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

Once the permissions are fixed, restart Apache.

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

Please read User switching (security) for details.

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

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:

mod_userdir is not compatible with Phusion Passenger at the moment.

VirtualDocumentRoot is not compatible with Phusion Passenger at the moment.

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

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

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

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

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

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

The general information section shows the following information:

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

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:

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:

Possible reasons why spikes can occur:

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

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

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

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

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

User switching can be disabled with the PassengerUserSwitching option.

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

Note that this feature does not apply to Rack applications.

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

You may notice that after each deploy, a new spawner server is created (it’ll show up in passenger-memory-stats). Indeed, Capistrano will deploy to a path ending with /current (ie : /u/apps/yourapp/current), so that you don’t have to care about revisions in your virtual host configuration. This /current directory is a symlink to the current revision deployed (/path_to_app/releases/date_of_the_release). Phusion Passenger recognizes applications by their full canonical path, so after deploying a new version, Phusion Passenger will think that the new version is a totally different application, thereby creating a new spawner server:

Don’t worry about this. The (old) spawner server will terminate itself after its timeout period (10 minutes by default), so you will not run out of memory.

If you really want to release the spawner server’s memory immediately, then you can add a command to your Capistrano script to terminate the Passenger spawn server after each deploy. That command is as follows:

Killing the spawn server is completely safe, because Phusion Passenger will restart the spawn server if it has been terminated.

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

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

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:

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.

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

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

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.

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:

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.

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.

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:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Notes:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

There are also cases in which unintential 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.

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

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

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

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