

Phusion Passenger 4.0 beta 1 is here - dRiek
http://blog.phusion.nl/2012/10/24/phusion-passenger-4-0-beta-1-is-here/

======
FooBarWidget
We are continuously improving Phusion Passenger, and we strive to be the best
application server out there when it comes to stability, reliability,
performance and ease of use. Not just for Ruby. If you have any feedback on
how we can improve, please let us know.

~~~
modernerd
Please extend the Passenger Enterprise $99/year "Startup" license to include
"hackers" as well as "startups, students, educational use, and non-profits".

I have a handful of pet Ruby projects in the pipeline which won't make money,
and I'd like to run them on a VPS using the Passenger Enterprise mass
deployment feature with rolling restarts. At $249/year, I'm not too keen. But
at $99/year I'd go for it.

~~~
tinco
If you don't make money, doesn't that make you a non-profit? If you do make
money, then you're either a startup or an established business. I don't know
what a "hacker" is in your context? Why does a "hacker" need mass deployment
and rolling restarts, while the feature is not worth 249 for him?

~~~
modernerd
I am not a registered non-profit. I am a developer with a day job who'd like
to host my side-projects on an inexpensive VPS using Passenger Enterprise.

As things stand, Ruby hackers can either host their pet projects on Heroku or
come up with a DIY solution to manage virtual hosts and graceful restarts on a
VPS.

In my opinion, the convenience of mass deployment and rolling restarts is
worth $99 for projects that do not make money, but it becomes a questionable
annual expense at $249. From the upvotes on my initial comment, I think that
others in my position may feel the same. And it seems like a good way to
encourage people who build things for fun to look to Passenger Enterprise for
their bigger, paid projects too.

------
drewda
Does this mean that Passenger can now run an EventMachine service next to a
Rails app?

------
tinco
Since our goal for Phusion Passenger is for it to become the ultimate polyglot
webserver, which technology would you guys want to see support for the most?

We're looking at Node.JS, Python, Haskell, Mono(C#), PHP. Do any of these
tickle your fancy or is there one missing?

~~~
hackerboos
Python most definitely.

~~~
tinco
We posted our passenger+python announcements on the Python reddit before, but
we didn't get much attention for it. Do you know in what way we could really
address the Python webdevelopment community?

~~~
jonastryggvi
post benchmarks cause the python community love those, and make it work nicely
with gevent. Just make a little hello world Flask app and show us how it
performs.

I use Passenger for my Ruby projects, but use nginx with gunicorn for Python -
no reason behind that choice whatsoever except that is the stack that I found
nice blog articles on how to get working with gevent

------
elektronaut
The ability to run multiple rubies is a very welcome addition, and just in
time now that Rails 4 drops support for Ruby 1.8. It's going to save us alot
of hassle transitioning legacy apps over. Thanks alot.

------
JimmaDaRustla
I'm having trouble seeing the value in Phusion with nginx and python/django
apps - I just use uwsgi.

Any big reasons to use it over said config?

~~~
FooBarWidget
See my reply here: <http://news.ycombinator.com/item?id=4693943>

------
gcao
Great work!

Node.js and python support will be nice.

~~~
JimmaDaRustla
I just use uWSGI - not sure what the added value for Passenger would be.

~~~
FooBarWidget
uWSGI requires another daemon which you must manage. With uWSGI, you must
configure Nginx to forward requests to that daemon. Phusion Passenger fully
integrates into Nginx so that is no longer necessary. With less moving parts,
there is less system administration overhead.

~~~
JimmaDaRustla
Thanks!

I didn't find it too difficult to setup uWSGI, but I can see how it can suck
if you have too many apps, or apps of different types.

~~~
unbit
The uWSGI project solved that "issue" (really, i have difficults calling it an
issue, but i can understand the point of passenger guys) with the "uWSGI
Emperor" more than one year ago in a pretty elegant (and system-friendly) way.
You may want to look at it.

~~~
JimmaDaRustla
Yup! I already use it - I have templated config files so I just create a
symbolic link when creating a new Django app.

I didn't have to configure Emperor mode on my new Ubuntu machine - it has a
directory where configs are stored. I remember 8 or 10 months ago, you had to
configure emperor mode and set the "vassals" directory, not anymore I guess.

------
moe
Still no zero-downtime restarts?!

I can only wonder what the phusion guys are thinking. Either way, stick with
unicorn.

~~~
FooBarWidget
We have had zero-downtime restarts (or, as we call it, rolling restarts) since
August 1 2012, in Phusion Passenger Enterprise:
<https://www.phusionpassenger.com/enterprise>

We also implement rolling restarts more conveniently than Unicorn:

* There are multiple ways to implement rolling restarts in Unicorn. One of them is by sending SIGUSR2. This makes Unicorn fork off a new master with the same number of workers. However this requires twice the memory usage during a restart.

* There are ways to script Unicorn to make it restart process-by-process, but this requires some effort.

* Phusion Passenger Enterprise implements rolling restarts with a single config option (PassengerRollingRestarts on), and it performs process-by-process restarting so that you don't need twice the memory usage. It automates _everything_ for you.

* The "deployment error resistance" feature, which can be used in combination with rolling restarting, ensures that in case your new app version doesn't start, it keeps the old processes around until an administrator manually tells it to restart again.

There are many other features in Phusion Passenger Enterprise which Unicorn
does not implement (e.g. live IRB console), or that we implement better. Take
a look, you may like it.

We are flattered that you like Unicorn. Being Unicorn contributors ourselves,
it's always good to see people contend with technology that we've contributed
to. :) Phusion Passenger 4 is the combination of all the experience that we've
built up in the past few years, in both Phusion Passenger and Unicorn.

~~~
moe
I didn't ask for a marketing pitch.

I just wanted to point out that your free product lacks a critical, basic
feature. Many passenger-users don't seem to be aware that they are serving
HTTP 502/503 error pages to their users _during every deploy_ unless they pay
$10 per server and month for your convenience.

~~~
FooBarWidget
If price is your biggest concern, then by all means, continue using free
products. We charge money because the money - and having a sustainable
business - allows us to develop the very best product and allows us to provide
excellent support.

It is not a secret which features are and aren't available in Enterprise. The
documentation and the website are very clear on this.

~~~
moe
_The documentation and the website are very clear on this._

For the longest time (until 2 months ago) your documentation and website were
not clear about it at all. It was simply not mentioned because passenger
didn't support it.

Since you take every opportunity here to inject your marketing hyperbole I'll
provide my counterweight: In my experience passenger is far from the "very
best" in any regard. Admittedly the last version I have used was 3.0.11.

The build-system used to be a trainwreck, plain and simple. At runtime I've
run into more than one failure mode where passenger would get stuck silently,
not providing any error message (not quite acceptable for a commercial
product). These were usually related to the Spawner getting stuck or
file/permission issues. I also once had a deployment where merely running
'passenger-status' would inexplicably hang the running passenger! (I did not
set that one up and never figured out the root-cause, we just migrated it to
unicorn).

In general, when people sit down and write training-wheels[1] for your
product, then you might want to strike a tad more humble tone in a hacker-
forum.

[1] <https://github.com/grosser/zombie_passenger_killer>

~~~
FooBarWidget
_"For the longest time (until 2 months ago) your documentation and website
were not clear about it at all. It was simply not mentioned because passenger
didn't support it."_

That's because Phusion Passenger Enterprise and the rolling restart feature
were only released 2 months ago. You can't exactly document something that
doesn't exist yet, can you? However we've already mentioned as early as last
year on the mailing list that there will be a commercial version and that
rolling restarts will only be available in there.

 _"The build-system used to be a trainwreck, plain and simple."_

I do not know what you mean by trainwreck here. Our build system is a simple
Rakefile with building rules that invoke the compiler, plus an installer
script that invokes Rake. Our build system goes through great pains to
autodetect as many things as possible, to avoid burdening the user. It even
goes as far as detecting bugs in the system and working around them. You can
read some of the source code here:

[https://github.com/FooBarWidget/passenger/blob/master/lib/ph...](https://github.com/FooBarWidget/passenger/blob/master/lib/phusion_passenger/platform_info.rb)

[https://github.com/FooBarWidget/passenger/tree/master/lib/ph...](https://github.com/FooBarWidget/passenger/tree/master/lib/phusion_passenger/platform_info)

As far as I know we are the only piece of software in our category trying so
hard. But if you are having problems with compilation, we would be happy to
help you.

 _"At runtime I've run into more than one failure mode where passenger would
get stuck silently, not providing any error message (not quite acceptable for
a commercial product)."_

Alright, here are the facts. Errors are always logged to the web server error
log. There are a limited number of known cases in which that does not happen,
or does not seem to happen:

1\. The user is looking in the wrong file. As strange as this might seem, it
actually happens. A classical example involves declaring the Nginx 'error_log'
directive inside the 'http' block. This makes Nginx open a log file, and all
the Nginx error logging functions write to that file, but it does not redirect
stderr to that log file. Since Phusion Passenger usually writes error messages
to stderr, the error message does not appear in that file, and the user is
confused. The solution is to move the 'error_log' directive outside the 'http'
block and into the global context.

2\. _Sometimes_ the error is written to stdout. Thanks to weird environment
issues on some systems (some OS X versions, I'm looking at you), stdout is
sometimes redirected to /dev/null so you don't see the error at all.

In Phusion Passenger 4 we've taken more extreme measures to ensure that errors
always get logged. For example we forcefully redirect stdout to stderr. If all
else fails, we provide a config option with which you can tell Phusion
Passenger to redirect its stdout and stderr to a file.

If you still encounter cases in which no error is shown, then we consider this
a bug and we could be happy to work with you to solve this problem.

 _"These were usually related to the Spawner getting stuck or file/permission
issues."_

So here are the facts again.

Phusion Passenger 3 and earlier assume that the app behaves correctly during
startup and shutdown. That's why it did not enforce any timeouts on these
operations. We have documented this extensively in our blog post "The right
way to deal with frozen processes on Unix":
[http://blog.phusion.nl/2012/09/21/the-right-way-to-deal-
with...](http://blog.phusion.nl/2012/09/21/the-right-way-to-deal-with-frozen-
processes-on-unix/)

However, starting from Phusion Passenger 4, we've much improved in this area.
Application processes now have a 1 minute limit to start. Otherwise, they are
killed with SIGKILL. Similarly, when you shut down the web server, the
Watchdog now kills all application processes with SIGKILL after a short
timeout, to ensure that no garbage processes stay behind.

If you still find the spawner getting stuck in Phusion Passenger 4, then we
consider this to be a bug and we would be happy to help you get to the bottom
of this. I do not know what you mean by file or permission issues, but again,
we would be happy to help you.

 _"I also once had a deployment where merely running 'passenger-status' would
inexplicably hang the running passenger!"_

There was in issue in the 2.0 series where passenger-status _could_ corrupt
internal data structures because a mutex was not being properly locked, but
this has been solved later in the 2.0 series. If this was not your issue, then
we would be happy to help.

"In general, when people sit down and write training-wheels[1] for your
product, then you might want to strike a tad more humble tone in a hacker-
forum."

The training wheels you mention predate Phusion Passenger Enterprise. Similar
training wheels exist for other app servers. However the existence of these
training wheels are not an indication of quality. Remember the Mongrel days
and that people had to monitor them using monit? This was not because of a
flaw in Mongrel itself, it was the apps and the libraries that caused crashes,
memory leaks, etc. Mongrel lacked protection against these kind of things, and
as a result got blamed for a lot of problems, but Mongrel was certainly not
the cause of these problems.

Similarly, Phusion Passenger only offered limited protection against
externally-caused problems. However with Phusion Passenger 4 and Phusion
Passenger Enterprise, we are moving more and more towards supervising every
single aspect of the system and making sure that things work even in the event
of external problems.

We do not, and have never, claimed that our products were without flaws.
However we are committed to fixing any flaws with continuing to add awesome
features. And by charging money we are in a much stronger position to commit
to this.

------
ghotli
I'm avidly looking forward to Python and Node.js support.

