Unicorn server works for 2 minutes, then crashes?


I'm trying to run my rails 3 application with webrick or unicorn. I
have ssh access so I can start the server that way, instead of doing
it with cPanel (which uses Mongrel).

When I type 'rails s -p 12003 -d' for webrick or 'unicorn_rails -p
12003 -D' for unicorn, I can access my rails app at domainname/
rails_app_name. I get the rails standard index page.
This only works for about 2 minutes. After that, the server is

I have a deployment server here, in my local network. And when doing
the exact same command 'rails s -D' (so on the default port) the site
just keeps running for hours. Works like a charm.

So what could be the problem? Is the application server crashing on my
webhost? When I open the log files it's just blank.


Is port 12003 a valid port for listening on with your webhost? They may be killing it after you start it.


One other thing, in addition to the port issue Bryan mentioned, could
be process monitoring. The web host may have something that monitors
processes by a whitelist, and terminates anything not on said list.
It's a way of trying to prevent security issues such as keyloggers and/
or other rogue processes from running.

Another possibility could be some form of compilation issue, such as a
missing library or something that didn't get checked during
compilation (not sure how that would happen, it's just a theory).
Your Unicorn process could be segfaulting after a certain amount of
time due to some kind of system incompatibility.

In any event, I think you'll need to contact a sysadmin at your host
company to get to the bottom of this. Wish I was more help man! Good

Thanks for the replies guys.
It appears the background process im trying to run gets killed as
mentioned in the above reply. I've asked if they could do something
about this but it isnt possible on a shared webhosting package. I
wonder why they can let a mongrel server run (cpanel) and not a thin,
passenger or unicorn ... server. I cant use mongrel cuz its only fully
compatible with rails 2.


Another option for you would be to switch hosts. Depending on your
experience with *nix administration, you could fire up your own Amazon
EC2 instance. I'm not sure what you're paying your present host now,
but generally speaking you get what you pay for. I find that Rails
hosting tends to be a bit more expensive, but that's probably because
it's still relatively "new" in the marketplace (as opposed to PHP,
Python, Perl, etc.) and have some more involved setups and needs.

Some options to consider if you're looking to switch:
- Slicehost
- Linode
- Amazon EC2
- Rackspace Cloud
- Heroku
- EngineYard

Some quick details to hook you up:
- Slicehost, Linode, Amazon EC2 and Rackspace Cloud are essentially
the same thing: virtualized private servers that install a base OS for
you, and it's up to you to take it from there, including installation
and configuration of database and web server. While you get maximum
control, you also have the full responsibility of keeping your system
up to date (patched against vulnerabilities, etc.).
- Heroku is a beast unto itself. Both it and EngineYard are
ultimately based on Amazon EC2, but they have special workflows and
setups defined for hosting Rails apps. Heroku has a no-write file
system, so you'll have to use something like an Amazon S3 bucket to
store uploads (like avatars, photos, etc.). Check out Heroku's
explanation on how things work at heroku.com for more details.
- EngineYard is different from Heroku in that it has some different
tools and concepts for setting up an application, and seems to be a
little more flexible/capable, but appears (to me, anyway) a little
more expensive (though not by much) for smaller setups, but cheaper
for larger ones, compared to Heroku. As with Heroku, check out
EngineYard's site at engineyard.com to find out how their system

Good luck!

Thanks for another quick reply Phoenix :slight_smile:

The hosts you've listed look great, but the problem is that none of
them offer unlimited data traffic.
We have started a pretty big project, but we don't know how much data
traffic we will generate and we wouldn't like to put our site offline
when we reached our data traffic or pay expensive bills.

The host we use at the moment offers unlimited space and bandwidth,
just not enough support for rails 3 unfortunately.
So we're stuck at choosing the right host. What would be the smart
thing to do here?


Ah, the great myth of unlimited bandwidth and space. There is no such thing. A shared host hosts hundreds of sites from the same server or cluster, if one (like yours) takes too many resources in any way, you’ll very soon discover that unlimited is not so unlimited (one of our customers experienced this first hand). There’s always fineprint that clearly defines what unlimited is. Just like ISPs use a fair use policy and advertise it as unlimited internet.

I always find it hard to believe how people see through a $3 pure gold necklace scam and fall for an unlimited shared hosting solution at $5/month. You always get what you pay for, and if unlimited traffic with an unlimited crappy service is your thing, then by all means…

You’re much better off going for a more expensive scalable service. If your traffic increases, it usually means your income also increases and you can just scale your service accordingly. It will save you the frustrations like you have now.

As for CPanel and mongrel, cpanel basically starts the mongrel in a confined (and very memory limited) user shell. As soon as you exceed the treshold (which usually is about 60MB of RAM), they kill off your mongrel (best case scenario kill and restart). Rails support comes with cpanel these days, but it’s what cpanel provides and don’t expect the sysadmins to know or want to do anything about that all-in-one package they install on the server. Top that off with an outsourced support center that won’t be able to help you out with anything Ruby or Rails related and you’re in for a very wild and frustrating experience.

Previous replies have recommended some scalable VPS services, go for one of those, it’s worth the extra buck.

Best regards

Peter De Berdt