Ruby Enterprise Edition on Mac OS X Leopard

I'm deploying Ruby on Rails apps on Mac OS X Server using Phusion Passenger (aka mod_rails) and Ruby Enterprise Edition. Passenger works beautifully, but REE crashes on startup each time. This seems to be specific to 64-bit Leopard Server — Tiger Server works fine.

A Quick Briefing

For those that don't know, Phusion is currently staging a revolution in the Rails world by addressing one of the platform's biggest obstacles: deployment. Passenger is an Apache module that makes deploying Rails apps nearly as simple as deploying PHP apps. That means no more dealing with CGI.

And beyond simply being a good concept, the actual Passenger installation process sets a new standard of usability in server-side software. The instructions are clear and succinct, and give suggestions when something goes wrong. The developers didn't have to do any of this to be successful, of course. I assume they simply wanted it to be a good experience.

In fact, installing Passenger is just this simple:
gem install passenger
passenger-install-apache2-module


The installer gives you the three lines you need to add to your Apache configuration file. Add those lines, restart Apache, and you're off and running.

In addition to Passenger, Phusion has also created their own fork of Ruby called Ruby Enterprise Edition. This is a version of Ruby specifically tuned for Rails apps running on Passenger, potentially using far fewer resources overall. Again, installation is very simple. You simply download the source and run the installer:
./ruby-enterprise-1.8.6-20080810/installer

Like Passenger, the REE installer is very conscious about communicating with the user and understands the goal of getting up and running quickly. It attempts to install the MySQL and PostgreSQL gems for you so you can just flip the switch and get started. It also installs into its own sandbox so it doesn't muck up your existing installation.

Once installed, you just need to change the three Passenger configuration lines in your Apache config file to use Ruby Enterprise Edition.

Crashes on Leopard

I've done all of the above on Mac OS X 10.4.11 Tiger Server, and it works great. However, running the exact same installation steps on 64-bit Mac OS X 10.5.5 Leopard Server causes REE to crash every time the app is launched. The Apache virtual host error log looks like this:
*** Unexpected error in Passenger: Cannot spawn application
'/my/site/path': The spawn server has exited unexpectedly.


Here's a snippet of the Ruby Enterprise Edition crash log (full trace available here):
  Thread 0 Crashed:
  0   libSystem.B.dylib               0x95eefb9e __kill + 10
  1   libSystem.B.dylib               0x95f66ec2 raise + 26
  2   libSystem.B.dylib               0x95f7647f abort + 73
  3   ruby                            0x00012570 rb_exc_new + 0
  4   ruby                            0x00083f5b sigbus + 27 (signal.c:612)
  5   libSystem.B.dylib               0x95eee09b _sigtramp + 43
  6   ???                             0xffffffff 0 + 4294967295
  7   libruby.1.dylib                 0x0054db08 rb_intern + 43
  8   libruby.1.dylib                 0x00509d43 rb_define_module + 32
  9   native_support.bundle           0x001b9dbd Init_native_support + 27
  10  ruby                            0x00010a82 dln_load + 226
  11  ruby                            0x0002e0f4 rb_require_safe + 1044
...

  
While Googling about this, I found a few notes about REE crashing when loading native extensions, and the MySQL gem is once such extension. I'm not certain this is the cause, but the trace above does makes it look that way a bit. When I switch the exact same app back to Leopard's built-in Ruby, everything works fine.

So far, I've only been able to find people running into the same crasher. The good news is that it crashes consistently at the same place, not at some random interval. For reference, I'm using Leopard Server's built-in Apache 2 installation. And when I tried to use Ruby Enterprise Edition, I did install the gems using REE, not the system's Ruby installation.
Design Element
Ruby Enterprise Edition on Mac OS X Leopard
Posted Nov 5, 2008 — 8 comments below




 

Nathan — Nov 06, 08 6523

Not having dealt with any of the programs you mention, my guess is an architecture mismatch. :)

Although I haven't dealt with Passenger, I have dealt a lot with Apache on Leopard. I had similar problems with mod_python. As you know, Apache in 10.5 runs as a 64-bit app on architectures that support it. This requires that all of the binaries it links to to be 64-bit, which requires the binaries those binaries link to to be 64-bit, etc. Of course, some of those same binaries need to be used by 32-bit binaries. Unfortunately, although Apple has an elegant solution with fat binaries, it isn't used any where else and so it isn't incorporated into a lot of open source build systems. This causes problems.

Python on Leopard is a frustrating example. All of the binaries for Python are 64-bit fat, except one: python. That's right, the Python intepreter, /usr/bin/python, is 32-bit only. So every script you run and module you import has to be 32-bit. I believe they had to do this for compatibility reasons. Whatever, just compile all your modules 32-bit, who cares? Web developers. Because Apache runs 64-bit, mod_python runs 64-bit, and everything they link to has to run 64-bit. So now those 32-bit extensions are producing crashes just like what you are encountering. Sometimes it's as simple as setting CFLAGS and recompiling, but sometimes it is a real pain in the ass. For example, you can't compile PostgreSQL as a 32/64-bit binary. The build breaks.

Enter lipo. Lipo is made for creating and manipulating fat binaries. So in the case of PostgreSQL, what you have to do is compile to different versions of it, one 32-bit and one 64-bit, and then use lipo to combine the two versions into one fat binary.

So, what you want to do is take every binary that mod_rails will link to and run 'lipo -info' on it ('file' also works) and ensure that they all have x86_64 binaries in them. If not, you've found your problem. Either recompile or download the a 64-bit binary and use lipo. Sounds like MySQL is the place to start.

BTW, /usr/bin/ruby is 32-bit. And iPhones were not made for writing long comments.

Scott Stevenson — Nov 06, 08 6524 Scotty the Leopard

@Nathan: my guess is an architecture mismatch

That seems possible, particularly considering the 64-bit changes in Leopard. I did some investigating and here's what I found:
Built-in Apache: httpd ppc7400 ppc64 i386 x86_64 Built-in Ruby (works): ruby ppc7400 i386 ApplicationPoolServerExecutable ppc7400 ppc64 i386 x86_64 mod_passenger.so ppc7400 ppc64 i386 x86_64 mysql.bundle ppc7400 i386 Ruby Enterprise Edition (does not work): ruby i386 ApplicationPoolServerExecutable ppc7400 ppc64 i386 x86_64 mod_passenger.so ppc7400 ppc64 i386 x86_64 mysql.bundle i386

Nothing looks odd to me here. The only difference is that REE doesn't include the ppc7400 variants. Side note: The version of Passenger using the built-in Ruby actually uses the one in Ruby.framework, not /usr/bin.

Thanks for taking the time to write all of that out, by the way. It was helpful.

Ben — Nov 09, 08 6528

On Leopard Client systems, /usr/bin/ruby is merely a link to /System/Library/Frameworks/Ruby.framework/Versions/A/usr/bin/ruby. I'd assume Server is the same way.

Ryan — Dec 10, 08 6561

I'm having this exact same issue with REE, Passenger 2.0.5, Apache 2.2.9, Leopard 10.5.5, and my usr/local install of MySQL 5.0.45.

I've also had the multi-architecture issue (mentioned in the Lipo comment) with macruby and readline not matching archs. See bug filed with Apple Ruby folks here here.

Since I'm relatively new at compiling from Unix source on a Mac (<2 yrs), I get hung up on these CFLAGS and other intricacies. Please let me know if you find a specific solution!

Ryan — Dec 10, 08 6562

Here's another clue. The Riding Rails weblog entry from last Friday was applauding 64 bit support in the latest version of REE (from the same day).

However, Phusion's post only claims their better 64-bit support has been tested against 64-bit FreeBSD 7 and 64-bit Ubuntu 8.10 Server. Their list of Officially tested platforms includes only Mac OS X 10.5.5 Server (x86).

I am not a 64-bit expert by any stretch, but I am seeing potential mismatches here, or at least untested versions.

DHH wouldn't be running Tiger?

Scott Stevenson — Dec 10, 08 6564 Scotty the Leopard

@Ryan: I am not a 64-bit expert by any stretch, but I am seeing potential mismatches here, or at least untested versions.

The two blog posts you linked to are very encouraging. I'm not sure what you mean by "potential mismatches," but both articles specifically cite OS X compatibility improvements. The Phusion post actually says "Various OS X-related crashes have been fixed."

It's true that they only mention FreeBSD and Ubuntu for 64-bit testing, but I assume someone tested Leopard since they mention it got fixes. I'll have to try installing the new version when I get a chance.

fatcow — Mar 20, 09 6625

We are adding that as an option on FatCow standard in house control panel.

Thanks for great post! Helped me while coding it!
Fatcow!

wall calendar — Feb 01, 10 7317

I dont understand why Ruby Enterprise edition crashes all the time. Phusion passenger seems to have no problem and this crashing specifically happens to Leopard 64 bit edition.

Phusion is currently addressing one of platform's biggest obstacles ié deployment, thereby creating a stge of revolution.Good thing passenger doesn't have to deal with CGI anymore because it deploys Rail apps nearly as simple as deploying PHP applications. What we find more interesting is that the passenger installation is easy. Its clear and succinct and corrects us by giving suggestions when something goes wrong. The ruby installation, however, seems to be a bit more hectic for me not because it isn't simple but because whenever I do it an error is showing up. I wonder why. Mine is a Leopard MAC OS X 10.5.5 Leopard. Maybe thats the reason!




 

Comments Temporarily Disabled

I had to temporarily disable comments due to spam. I'll re-enable them soon.





Copyright © Scott Stevenson 2004-2015