En dev bootstrap mt psgi

semuel edited this page Aug 20, 2012 · 7 revisions
Clone this wiki locally

Table of Contents


To get MT up-and-running over PSGI using mt.psgi, we need a couple of related Plack / PSGI Perl modules.

Luckily, someone already did the hard work for us, and collected them all under Task::Plack, and all you need is to install it on the machine. Use your CPAN shell, or if you have cpanm installed:

 # cpanm Task::Plack
 # cpanm XMLRPC::Transport::HTTP::Plack
 # cpanm Starman

The second line of the three above, installing XMLRPC::Transport::HTTP::Plack, as we need it for XMLRPC (mt-xmlrpc.cgi). The last line is for installing Starman, our preferred PSGI server. So if you plan to use it, this will do all the work of actually installing it.

Recommended PSGI Servers

mt.psgi is developed on Starman as it is easy to make changes and see their effect immediately, so Starman is our reference environment.

For production environment, we recommend either Starman (using prefork server type) or plackup are expected to give production level of service.

Setting MT_HOME Environment Variable

Whenever running MT, MT always assumes that either the current directory is the root directory of the MT installation, or failing that, MT_HOME is pointing to MT's installation

Apache usually 'cd' to the script directory before running the scripts. The PSGI servers do not. so either set MT_HOME or manually 'cd' to the correct directory before running plackup / starman

Internal Deadlock on HTTP Request

The plackup server is fast, light and easy to use, but it have one problematic feature: it handles requests sequentially, and not in parallel.

While this is generally OK, there is one case, with Trackbacks, it can cause deadlocks. for example:

  • If you can making a Trackback between two blogs that are hosted on the same installation
  • The TB making operation is trying to access the second blog's response
  • But the second blog can not response, because the server is busy with *making* the request
Currently there is no workaround for this, and no resolution is planned. We advise that for systems where trackbacks are enabled, use a parallel or preforking server for production (i.e. Starman or mod_psgi on Apache)

Server Settings


If you make a configuration change that affect the behavior of the entire application, mt.psgi will attempt to restart the application. i.e.:

  • After completing install or upgrade
  • Changing system configuration such as debug mode
  • Adding or deleting a custom field
It is done by sending SIGHUP signal to the server. But for MT to send this signal, the server needs to tell MT its process id.

This is done by using PID files, usually stored (on *nix systems) in /var/run. So here is how we tell Starman where to his pid file, and MT where to find it:

 # then run starman
 $ starman --pid /var/run/mt.pid ./mt.psgi