I'm running ror app(rails 2.3.5,ruby 1.8.7) on my vps.
Whenever I restart my apache server all the working subdomains are going down. I've passenger version as 4.0.5, I wonder what would be the reason. I'm pasting my apache error log
Check this page on the Phusion Passenger wiki for solutions.
Also, you should upgrade to the latest version (4.0.29) which fixes many bugs and brings many improvements. The error message in the latest version actually links to the page that I linked to.
Related
I'm trying to get a simple 'hello world' RoR app deployed using Apache/Passenger on Ubuntu 12.04 (via Linode). I followed the directions on the Phusion Passenger documentation site. I get the Passenger error screen that says:
Ruby (Rack) application could not be started
The backtrace is here: http://pastebin.com/Sr4PaQvB
My apache virtual host config is here: http://pastebin.com/q2vb0hX8
One thing that is confusing me is why Passenger is not using the ruby (and gems) that I have installed via RVM even though I specifically use SetEnv and 'PassengerRuby` to tell it where to look. I appreciate any advice! Thanks!
The reason why Passenger wasn't loading up the right ruby/gems was because RVM wasn't installed correctly. I reinstalled RVM and reconfigured my app setup for the correct gems and all was well.
We migrated our rails app. from Mongrel to Phusion Passenger recently. We had this mongrel_proctitle, which used to show the process title in top.
This was useful feature for troubleshooting. Are there anyway of getting similar functionality with Phusion Passenger?
Passenger already automatically sets useful process titles. All your Ruby apps are called "Passenger RackApp: /path-to-your-app". If you need to obtain statistics, just run passenger-status.
As we (finally) port our apps away from Ruby 1.8.7, I am trying to set up Phusion Passenger and Apache, with RVM, to serve apps using both Ruby 1.87/Rails 2.3.x and Ruby 1.9.3/Rails 3.2.x. This is all on my development machine; in production we us separate VMs to serve the two different platforms--but needless to say, that would be inconvenient in development.
The Good: I've got Passenger 3.0.7 installed using Ruby 1.8.7 (and RVM), and 1.8.7/Rails 2.3.x apps work great as they have in the past (the only thing changed from my past setup is having (re)installed Passenger via RVM).
The Bad: I also have installed Passenger 4.0.20 as a gem using Ruby 1.9.3 (and RVM), and if I configure Apache to use them, it is able to serve up a 1.9.3/Rails 3.2.x app just fine. But Passenger can't serve the Ruby 1.8.7/Rails 2.3.x app.
Another developer here has essentially the same setup working but we are unable to see any clear differences between her installation and mine. But her success tells me it is possible.
The Ugly: When I try to run the 1.8.7/2.3.x app with Passenger 4.0.20, Passenger logs a bunch of output to the Apache error.log, including these lines:
[ 2013-10-22 13:12:30.1770 21240/7fe89ad0e700 Pool2/SmartSpawner.h:301 ]: Preloader for /home/username/workspace/app started on PID 21284, listening on unix:/tmp/passenger.1.0.21232/generation-0/backends/preloader.21284
[ 2013-10-22 13:12:30.2547 21240/7fe89ac8c700 Pool2/Implementation.cpp:1274 ]: [App 21284 stderr] [ 2013-10-22 13:12:30.2547 21385/0x7f9bf1fd0b80(Worker 1) request_handler/thread_handler.rb:197 ]: *** Passenger RequestHandler warning: someone tried to connect with an invalid connect password.
It's the last bit (scroll to the right!) that seems the most bizarre.
Some online searching reveals that Passenger supports some sort of 'connect password' but we are using no such thing. There are few Passenger-related references to 'someone tried to connect with an invalid connect password' outside of the Passenger source code.
I actually have solved this problem, but due to the dearth of references on the web, and my failure to find any mention of the 'invalid connect password' error here on SO, I am posting this to help the next person. I haven't included lots of other log snippets, configuration file contents and the like, because I have already mentioned all the relevant information.
If you think you know the answer, here's your chance to get some more 'reputation'. Otherwise, I'll post my answer in a couple days.
Phusion Passenger author here. The connect password is a security mechanism in Phusion Passenger to prevent unauthorized processes on the local system to connect to the spawned application processes. The connect password is only known to the HelperAgent, the app process and admin tools like passenger-status.
I'm not sure what went wrong in your case. I'd like to analyze your problem more deeply. Could set PassengerLogLevel to 3, trigger the problem, and post the contents of your Apache error log file to the community discussion forum?
I found my answer in a passing remark on the Passenger forum.
Quoting my question, here is the real problem: "I also have installed Passenger 4.0.20 as a gem using Ruby 1.9.3 (and RVM)..."
I was able to solve it by re-installing Passenger 4.0.20 as a gem using Ruby 1.8.7 (and RVM). With this configuration, Passenger is able to serve up both Ruby 1.8.7 and Ruby 1.9.3 applications.
I have read that in addition to its mainly-native code, Passenger uses a bit of Ruby internally, interpreted by whatever version of Ruby it was installed with. Apparently (and wonderfully) this Ruby code is compatible with Rubies as ancient as 1.8.7. Equally wonderful, it will serve up applications with whatever Ruby their PassengerRuby directives specify... but apparently this isn't the case if Passenger is installed using a newer Ruby than the one needed by the application.
Big thanks to the Passenger and RVM teams, and also to Maximilian Herold for solving my mystery.
weird issue. I have passenger installed on an Apache 2 server, and trying to get a Rails application running. First time deploying a rails application, so not really sure what's going on.
Passenger gives me this error:
But the problem is that 1.9.2-p136 isn't even installed on my system. I removed all ruby versions and completely reinstalled ruby with 1.9.3-p448. (I also have 2.0.0 but I default to 1.9.3)
Not seeing how passenger is even recognizing that I am running a build of ruby that doesnt exist on my system.
I'm hoping this is my last obstacle to getting this started. I have dealt with about every issue that I could have trying to get this damn rails app up. I'll tell you, they make up for how easy it is to develop with by making it impossible to deploy.
Thanks all!
1.9.2 is probably the system ruby (or was, at some point). Now, how in the heck Passenger is running on that while simultaneously using gems from an rvm install of 1.9.3...
Anyway, check your Passenger config. Make sure the PassengerDefaultRuby (if present) and PassengerRuby directives are pointing to the correct version; Passenger often gets confused by varying PATHs, and this is especially true with rvm where you may be running a different version in your user shell session than system tools will find on their own.
There's a reason people like solutions like Unicorn, Puma, and Rainbows. ;) Passenger, once you get it compiled and configured, is pretty much fire and forget, but getting to that point can be painful.
I want to run multiple rubies on our production server. We have some ruby 1.9.3 rails 3.2 sites going live as well as keep older 1.8 sites. I understand that Passenger 3.2 will be able to do this natively but isn't live yet.
So for now, is this the best way to do this?
http://blog.phusion.nl/2010/09/21/phusion-passenger-running-multiple-ruby-versions/
The apache passenger module can't do this. You could however run passenger standalone for each app (with a different ruby version) and then proxy from apache to passenger standalone.
You could of course also proxy to unicorn, thin etc.
What about using multiple VMs/Slices for your different versions of ruby and rails, that way you have more control of your enviroment and don't have to worry about your different rubies/rails causing headaches with each other.
EDIT
Another solution that I have heard of but haven't tried is setting multiple users and running each version of ruby/rails per a different user