passenger

void 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/tree/master/lib/ph... 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... 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.