I'm using Phusion Passenger 2.2.2 with a Rails 2.3.8 and 2.3.2 apps. Every once in awhile it will freeze and there is no response from the server when trying to access the rails applications. There is nothing in the apache log or the rails logs. I'm not talking about a 500 error or anything, there is just no response whatsoever. They don't respond until we restart apache.
I tried to follow these instructions to try to get a stack trace: http://www.modrails.com/documentation/Users%20guide%20Apache.html#debugging_frozen
I sent SIGABRT to the processes, according to the instructions, and they did not seem to care. Didn't see anything in the apache or rails logs.
The way to troubleshoot this problem on Passenger is to issue a kill -SIGABRT to the stuck Rails processes, and find their backtrace in the Rails log
Related
I am running RSpec integration tests with JavaScript enabled on my rails project and am receiving the following error after using the capybara method visit to go to my sign in page:
We're sorry, but something went wrong. We've been notified about this issue and we'll take a look at it shortly. Information for the administrator of this website:
The Phusion Passenger application server encountered an error while starting your web application. Because you are running this web application in staging or production mode, the details of the error have been omitted from this web page for security reasons.
Please read https://www.phusionpassenger.com/library/admin/log_file/ to find the details of the error.
(Note that the previous error message is what appears in the HTML of the page after running print page.body, but I removed the HTML tags for ease of reading)
The strangest thing is that we are not using Phusion Passenger in our project (this been confirmed with the project leader). Accordingly, there is no passenger gem in the Gemfile and running passenger stop returns: passenger: command not found
Any guesses on how this could be?
My configuration
using capybara and capybara WebKit
my other RSpec tests using capybara work fine, when :js => false
The port that I was connecting to when visiting the sign in page was incorrect, and that somehow connected me to Phusion Passenger.
Credit goes to Thomas Walpole for his help in the comments.
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.
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.
My website runs normally to me but CTR is very low so I open the error log and see something like from this file:
crash log
What is this and how can I fix this?
P/s: I'm using Phusion Passenger 4.0.10, nginx 1.0.15, rails 3.2.12, ruby 1.9.3p448, Centos
I'm running Rails 3.0 with a custom Devise authentication strategy that makes an SSL call using Curb. I get an "Curl::Err::HostResolutionError (Couldn't resolve host name)" error. Works fine manually from the command line.
The production environment is Apache running Passenger standalone with rvm 1.9.2#rails3, because the main Passenger is running ruby 1.8.7 and rails 2.3.4. I don't get this error with the my other app running the earlier versions of ruby and rails. Same code, but the difference seems to be Devise.
I've read elsewhere that this might have something to do with DNS and Apache, but I can't for the life of me figure this out and I'm really grasping at straws here. Any ideas would be greatly appreciated! Thanks in advance!
The issue actually turned out to be related to user permissions. When I ssh in with my user account and start Passenger standalone, no problem. When I start it remotely from Capistrano with the deploy user I get the error.