Description of problem:
When running a Ruby 2.0 cartridge, Passenger (app that handles threads as Apache module) tries to create and write to a temp directory defined as /tmp/passenger/passenger<instanceinfo>.  If the /tmp/passenger directory does not exist, it is created by the application with 700 rights.  So, the next gear to exist on the same host tries to create the directory in /tmp/passenger/passenger<instanceinfo> and fails, ultimately failing to start the gear.  This can occur on new application creation or on scaling up a gear.


Version-Release number of selected component (if applicable):
OpenShift Enterprise 2.x

How reproducible:
Every time when creating Ruby 2.0 applications

Steps to Reproduce:
1. Create a Ruby 2.0 application 
2. Scale the application

Actual results:
The second gear fails to access /tmp/passenger directory

Expected results:
The second gear is successfuly created.

Additional info:
The first solution is to modify your base Ruby-2.0/1.9/1.8 cartridge file(s)   versions/<VERSION>/etc/conf.d/openshift.conf.erb:

Remove:
PassengerTempDir /tmp/passenger

Replace with:
<%
  temp_dir = "/tmp/passenger.#{ENV['OPENSHIFT_GEAR_UUID']}"
  Dir.mkdir(temp_dir) unless File.exists?(temp_dir)
%>
PassengerTempDir <%= temp_dir %>

This cannot be handled easily by the OpenShift users, as the Ruby-2.0 cartridge gets re-copied from your servers on gear addition, so the change needs to be made on the global Ruby cartridge.

The second solution would be to create and chmod 777 a /tmp/passenger directory on all hosts to prevent the issue from arising—however there could still be conflicts if a second gear came up and eventually used the same PID as one that had come up before it on another gear (so two gears trying to use the same /tmp/passenger/passenger.PID dir), and hadn’t cleaned it up.

A third solution would be to somehow have a custom-mounted /tmp directory for each gear, if Openshift Enterprise allowed that.  If this is already the case, then there is at least one server that did not handle this properly and failed to start the gear.

Without this change, any Ruby-based application that goes to production runs the risk of a) being unable to scale up when necessary, and b) not properly starting up if moved to a new host, a significant hurdle to calling it production-ready.