Passenger Troubleshooting

From DreamHost

Jump to: navigation, search

Contents

Common Problems

Below are some of the most common Passenger-related problems people run into.

Session Errors Relating to Rack

This is perhaps the most common problem. The problem is that Rails 2.3.x is incompatible with versions of Passenger prior to version 2.1.2. Many of DreamHost's older Sarge boxes are running Passenger 2.0.6. You can find out what version of Passenger the apache service your site is being hosted on is using by creating a PHP script named phpinfo.php with the following contents: 

<?php
phpinfo();
?>

Upload that to your site and browse to it, then search for "passenger". You should see a line similar to this: 

Apache/2.0.63 (Unix) PHP/4.4.7 mod_ssl/2.0.63 OpenSSL/0.9.7e mod_fastcgi/2.4.2 Phusion_Passenger/2.0.6

As you can see, in that case the Apache service was using Passenger 2.0.6. If your server is running version 2.0.6 you can contact DreamHost tech support and request that Passenger either be upgraded on your machine or that your account be moved to a server that already has an upgraded version (there seems to be a problem with some of their older Sarge boxes that keeps them from updating to the newest version, so you might have to move to get access to a newer version). All newer machines should be running Passenger 2.2.1 as of the time this was written.

Application Not Restarting

This generally isn't actually a problem -- it's only a perceived problem. In versions of Passenger prior to 2.1, you would restart your application by touching the restart.txt file in the tmp directory. The next request your application processed would restart it and remove that file. Thus, the common practice to see if the application restarted was to see if the restart.txt file was still there or not. In Passenger 2.1 the behavior of the restart mechanism changed. Now Passenger simply checks the modification timestamp on the restart.txt file. If it's more recent than the last time it checked, it restarts. The file is not removed. This was done in large part so that restarting applications would work seamlessly on NFS shares. On lower traffic sites, you can usually still visually see the application restarting by "priming" a page (loading it a couple times in your browser), touching the restart.txt file and then loading that page again. It should take a noticeably longer time to load than it had the previous couple of times. This won't really work on live sites that are getting traffic though as it's entirely possible another person's request restarted the application by the time you test it yourself.

Broken Pipe Error

If you get an error message mentioning a broken pipe with the exception class PhusionPassenger::Railz::ApplicationSpawner::Error as depicted in the image to the right, then you're most likely running into memory limit problems. Basically, what's happening is the request being processed by Passenger caused your user memory limit on the server to be exceeded and the Rails process that was handling that request was killed. If you're seeing this error, then it's usually a dead giveaway that this is happening. Unfortunately, there isn't a whole lot that can be done about this since even a very basic standard Rails application requires a lot of memory up front. In fact, enough memory to hit your memory limit almost immediately -- especially if you have other websites being hosted on your account. This will happen even more frequently if you have more than one Rails application being hosted from the same account. The best way to ensure that you don't run into this problem is to move your Rails sites over to a DreamHost PS. That will give you guaranteed, scalable memory that you can adjust until your memory needs are met.

Production Log Isn't Being Written To

This problem can be a bit tricky to figure out until you know what causes it. It's almost always caused by a misconfigured database.yml file. If your database.yml file isn't configured correctly Passenger will die a horrible death before your application is even loaded. As such, you get no helpful error messages from Passenger and your production.log file isn't touched.

Missing connection settings

Some versions of Passenger really don't like it if your database.yml file doesn't at least include settings (they can be blank) for all environments. The symptom of this happening is your application endlessly loading with no output to the production.log file. So, make sure you leave the connection information for all environments in your database.yml file -- even if you're only using the production settings.

Using a socket connection rather than a host

This mistake is simply not changing from using a socket connection to a host. The default MySQL connection information looks like this: 

production:
  adapter: mysql
  encoding: utf8
  reconnect: false
  database: bar_production
  pool: 5
  username: root
  password: 
  socket: /tmp/mysql.sock

As you can see, it's configured to use a socket connection by default. You need to make sure you replace that line with correct host, username, and password information for a database created in the Goodies -> Manage MySQL area of your web panel. A correct configuration might look like this: 

production:
  adapter: mysql
  encoding: utf8
  reconnect: false
  database: bar_production
  pool: 5
  username: exampleuser
  password: jWr873dnaiu12
  host: mysql.example.com

Misnaming parameters

Another common mistake is simply having a necessary parameter misnamed. This can happen easier than it sounds because when you generate a Rails application it defaults to generating a sqlite3 database.yml configuration file. You have to manually specify that you want a MySQL file (rails --database mysql <projectname>) or you'll have to change it manually. Since a lot of people don't realize this, they end up changing it after the fact and sqlite3 config files don't have username or host parameters! Here's what a default sqlite3 section looks like: 

production:
  adapter: sqlite3
  database: db/production.sqlite3
  pool: 5
  timeout: 5000

So, it would be easy enough to modify that to look something like this: 

production:
  adapter: mysql
  database: bar_production
  pool: 5
  user: exampleuser
  password: jWr873dnaiu12
  host: mysql.example.com

See the problem? In that configuration the "username" parameter was called "user" instead. This is a very common error and easy to miss. It should actually look like this: 

production:
  adapter: mysql
  database: bar_production
  pool: 5
  username: exampleuser
  password: jWr873dnaiu12
  host: mysql.example.com

Uncommon Problems

Below are oddball problems you may encounter when running under Passenger.

ERB comments cause the beginning of your view to vanish

You may be tempted to begin a view with a comment to help you remember which file you're editing. This can be helpful if, say, you have "index.html.erb" under many different controllers. You may be tempted to do this:

This view is broken: 

 <% # Help controller index: %>
 <p> blah blah blah...
 <%= link_to "help topic 1", help_topic_one %>
 more blah blah blah</p>

What will happen is that the erb processor will summarily treat as a comment everything up to the next erb directive. It will literally not appear in the output stream sent to the browser. In the above example, the view will start with the link, eliminating everything prior to that: 

 <a href="/">help topic 1</a> more blah blah blah</p>

As you can see by the dangling </p> tag, this can easily break your DOM structure, causing all sorts of problems both for your CSS directives and any Prototype / JQuery / AJAX stuff you've got going on.

You will be surprised by this bug, because the above view renders exactly as it should under mongrel in a development environment.

The solution, obviously, is to eliminate the comment or replace it with an old-school HTML comment (the <!-- kind).

Retrieved from "http://wiki.dreamhost.com/Passenger_Troubleshooting"
Personal tools