I have an apache2 server running Phusion Passenger. On this machine I have two virtual hosts setup each look like this (path's are different for the 2nd virtualhost...but other directives are the same)
ServerName beta.mysite.us
DocumentRoot "/var/www/beta/mysite/public"
<Directory "/var/www/beta/mysite/public">
RewriteEngine on
AllowOverride All
Options FollowSymLinks
</Directory>
# http://www.modrails.com/documentation/Users guide.html
PassengerAppRoot "/var/www/beta/mysite"
RailsEnv development
PassengerMaxPoolSize 6
PassengerDefaultUser mysite
# PassengerHighPerformance does come at a trade off of lack of support for mod_rewrite
PassengerHighPerformance off
RailsSpawnMethod conservative
RailsFrameworkSpawnerIdleTime 0
RailsAppSpawnerIdleTime 0
PassengerPoolIdleTime 300
ErrorLog "/var/log/httpd/mysite-beta-error_log"
CustomLog "/var/log/httpd/mysite-beta-access_log" common
Apache starts fine. I can go to one of the virtualhosts and it will load Rails and work. When I go to the second virtualhost, a ruby process spawns ("Rails: /var/www/mysite/current" according to ps awuxf) and uses 100% CPU. This process never exits. At this point neither virtualhost is responsive. If I kill the the offending ruby process, another ruby process replaces it and uses 100% cpu. If I kill these processes about 5-6 times, then both virtualhosts respond but they, are somehow, running the same Rails app?!
I have another virtualhost on this machine that is not setup with phusion passenger..This one never exhibits any problems.
Any help / ideas would be much appreciated!
I would recommend switching to nginx
I had faced similar issues with phusion passenger, with no success in debugging. Later, I switched to apache2+mongrel with mod_proxy. I have seen best stability with nginx though. nginx FTW :)
The obvious thing would be to check you don't have any inadvertent infinite loops or impossible to finish conditions in any of your application. It's all too easy to do a find(:all) by accident on a table too massive to fit in memory.
Does it jam immediately or is there something you must do to trigger it? For example, loading a specific page, or not loading a page at all. There could be something in an initializer that causes trouble.
Being able to power up script/console is always a good sign, especially if you can load records. There's not a lot of information in your description. A copy-paste of the output of 'ps aux' would help.
Is it possible you have some code causing this? We have a number of apache/passenger installations. It's more likely something with your code than aapache/passenger.
(A reminder to my future self)
I recently inherited a Rails 2.3.x/Ruby 1.8.7 app running on Passenger and Apache2. I updated RubyGems from an old 1.3.x to 1.6.2, and immediately noticed a ruby process spiking to 100% when passenger loaded. Downgrading to RubyGems 1.5.3 resolved the issue.
Related
Has anyone encountered problem of running Puppet Dashboard on Ruby Passenger 5? If yes does it really work with that Passenger version?
I've already setup and configured the necessary files required to run Puppet Dashboard via Passenger. Currently, the Apache test page is shown instead of the dashboard menu. This will not appear if Puppet-Dashboard is run in the lightweight Webrick server.
While scouring most of the installation samples and the manuals on how to install and configure it for Centos 6. I've seen most of them were based on Passenger 3 / 4. I am currently using 5.0.10 as it is used in conjunction with Puppet 3.8.1. One thing certain is that RailsAutoDetect is deprecated in version 5 and that has been commented out.
Below my puppet-dashboard.conf file (the load module has been moved to another file to avoid double-instantiation)
On the logs, the first error reported is that the path of /usr/share/puppet-dashboard/public/reports/upload is not there, so I've created those sub-folders to see if what would be the next error.
The next error in the log file after that is now shown like:
Attempt to serve directory: /usr/share/puppet-dashboard/public/reports/upload/
External node and node terminus option has been commented out as not to disrupt normal puppet run-interval activities during office hours.
PassengerHighPerformance on
PassengerMaxPoolSize 6
PassengerPoolIdleTime 1500
PassengerStatThrottleRate 120
Listen 3000
<VirtualHost *:3000>
ServerName mi-cloud-mgmt-config-01
ServerAlias mi-cloud-mgmt-config-01.mimos.local
RailsBaseURI /
PassengerAppRoot /usr/share/puppet-dashboard/
DocumentRoot /usr/share/puppet-dashboard/public/
# UPDATE THIS TO YOUR FQDN
<Directory /usr/share/puppet-dashboard/public/>
Options None
Order allow,deny
allow from all
</Directory>
ErrorLog /var/log/httpd/dashboard_error.log
LogLevel debug
CustomLog /var/log/httpd/dashboard_access.log combined
ServerSignature Off
</VirtualHost>
Yes I have encountered the same issue. I tried to be clever and use the latest passenger for my Puppet Master as per the Puppet guide... https://docs.puppetlabs.com/guides/passenger.html#install-rackpassenger
But it looks like Dashboard doesn't support Passenger 5.x. Which is fair enough considering Dashboard is basically dead.
I noticed the structure of the directories under the <DocumentRoot> and <Directory> were different for Dashboard compared to Puppet Master, namely no config.ru being present.
So on CentOS 6 I tried the version of mod_passenger from EPEL repo mod_passenger-3.0.21-11.el6 and that worked for both Puppet Master and Dashboard.
According to some knowledgeable folks in #puppet IRC there should only be a minor lowering in performance with 3.x compared to 5.x.
Although it might need some tweaking it does work on passenger 5.
I use Nginx but if it works using Nginx it should on apache as well.
I use passenger-5.0.13 with ruby 1.9.1 to run puppet dashboard.
I've been stuck on this for a few weeks and I've run out of ideas.
I am trying to move two Ruby sites to a new server. One is working flawlessly and the other gives the Connection closed error.
It should be a standard Apache + Passenger 3.0 + Ruby 1.8.7 + Rails 2.3.18 setup.
Both Ruby sites are based on the same code with slight differences.
I'm also not a Ruby guy, I just administer the servers however the developers are out of ideas on this issue.
Apache's error log with Passenger debugging turned to maximum shows this:
[ pid=23816 thr=139877253064448 file=ext/common/ApplicationPool/Pool.h:939 time=2013-05-15 14:19:28.87 ]: Spawning a process for /home/xxxxx because there are none for this app group
[ pid=23816 thr=139877253064448 file=ext/common/ApplicationPool/../SpawnManager.h:289 time=2013-05-15 14:19:28.88 ]: Spawning a new application process for /home/xxxxx...
[ pid=23816 thr=139877253064448 file=ext/common/ApplicationPool/Server.h:292 time=2013-05-15 14:19:34.141 ]: Client 28: SpawnException occured (with error page)
So it tries to spawn the app and it fails. I can't locate any logs which explain why it is failing however.
Running ./script/server from the app's root folder works fine so everything must be more or less working correctly with the app.
The Apache config file is pretty straight forward and fairly basic: (simplified slightly)
PassengerRoot /var/lib/gems/1.8/gems/passenger-3.0.19
PassengerRuby /usr/bin/ruby1.8
PassengerEnabled off
PassengerUserSwitching on
PassengerLogLevel 3
<VirtualHost *:80>
ServerName xxxxx.com
ServerAdmin webmaster#agentpoint.com.au
DocumentRoot /home/xxxxx/public
PassengerEnabled on
PassengerAppRoot /home/xxxxx
PassengerTempDir /home/xxxxx/tmp
PassengerUploadBufferDir /home/xxxxx/tmp/uploads
</VirtualHost>
Does anyone know how this error could be occuring given the fact that a nearly identical code base works fine? And what logging should show a spawn error like that? I really am missing that crucial step that is failing and I can't figure out what it is doing precisely.
Could you upgrade to Phusion Passenger 4? That would potentially solve your problem. If not, then Phusion Passenger 4 has much better error reporting. It will print the error reason to the logs.
I have one dedicated server with below configurations
i3 - Dual Core - 3.06Ghz H/T
16GB RAM
500GB SATA2
Now I want to execute two different Rails application on one dedicated server. A both application are different but they are using common database.
Is it possible to do that? If yes – How can I do that?
Is Phusion Passenger with Apache a good approach? If yes - How can I configure two application with one Phusion Passenger server?
I will describe how I run multiple Rails applications on one Linux server, using Apache, Phusion Passenger, and some version of Ruby. You have many choices, but this should help you get started. Many of these details come from the installation script
First, install Phusion Passenger.
> gem install passenger
Second, build the Apache 2 Passenger module. You should be able to execute the following script installed during step one.
> passenger-install-apache2-module
This script will compile the Apache 2 module and explain how to configure Apache. If dependencies are missing the script should offer some helpful advice about how to install them.
Third, edit your Apache configuration file. I have to add something like this. (Just use this for references and don't worry about .rvm) The script run in step two will give you something that you can copy and paste.
LoadModule passenger_module /Users/me/.rvm/gems/ree/gems/passenger-3.0.9/ext/apache2/mod_passenger.so
PassengerRoot /Users/me/.rvm/gems/ree/gems/passenger-3.0.9
PassengerRuby /Users/me/.rvm/wrappers/ree/ruby
Fourth, add something like this to your Apache configuration file for each application you want to run.
<VirtualHost *:80>
ServerName app1.example.com
DocumentRoot /somewhere/app1/public # <-- be sure to point to 'public'!
<Directory /somewhere/app1/public>
AllowOverride all # <-- relax Apache security settings
Options -MultiViews # <-- MultiViews must be turned off
</Directory>
</VirtualHost>
If you have two Rails application sharing one database then they will both have similar connection information in config/database.yml
Yes, It's definitely possible. I've never done it with Passenger + Apache, but I'm sure thats a fine way. I've only ever done it with thin + nginx.
Passenger Phusion with Apache is a solid approach. The fact that they are using the same database shouldn't be a problem (just make sure they don't step on each other in any way).
Generally, just set things up as normal, but take a look at Apache name-based virtual hosts:
http://httpd.apache.org/docs/2.2/vhosts/name-based.html
Using Rails 3.0.1, Apache 2.2.9, and Passenger 3.0.0 on Debian.
For some mysterious reason, the Rails app is coming up in the development environment. I've double-checked the Apache configuration, the VirtualHost files, and so forth, and there are zero instances of "RailsEnv" or "RAILS_ENV" either in /etc/apache2 or in the app directory itself.
Worse, even if I do put a "RailsEnv production" line into the Directory block in the VirtualHost file, it makes absolutely no difference, and the app still comes up in the development environment.
Nothing interesting is logged if I set PassengerLogLevel to 1.
Any help either with what the problem is, or at least a course of action to identify the problem, would be greatly appreciated.
That's because with config.ru your app is detected as a Rack app, not a Rails app, and thus you need to set RackEnv instead of RailsEnv. A "Rails" app refers to a "Rails 1 or 2" app. Rails 3 apps are considered to be Rack apps.
After thrashing around for a while and trying random things off the 'net, I've found that deleting the config.ru file Rails generated solves the problem without otherwise causing the app to cease functioning. Why this was causing the problem remains unknown to me, but anybody coming across this having the same issue might try that solution.
Same symptom here, but none of the suggested solutions work for me. I first noticed this when I set my <body> tag to be <body class="<%= Rails.env %>"> and defining a background-color for the development class that is distinctly different from the background-color in the production class. All I ever see (production & development) is the development color. And of course viewing the source of the web page in the browser shows that the class being generated is development. I renamed config.ru to ~config.ru and restarted Apache2 and that didn't have an impact. I added RackEnv production to my *:80 virtual host file where the other Passenger attributes are set. That didn't have an impact. So I reset ~config.ru to be config.ru, restarted Apache2 and still don't see a change. I appreciate the explanation given by #Hongli of a Rack startup versus a Rails startup. I just wish my server would listen to him! I even did a recursive listing grepping for .htaccess -- none found. At least I think I know now where to keep poking around.
Apache 2.2.15, Rails 3.0.3, Passenger 3.0.2, Mac OS X Server 10.6.6
Is this even possible?
I have a Rails app running on Passenger and a mod_perl site that need to run on the same server. I've tried setting up two VirtualHosts and I've tried just using one VH and an Alias/Location for the mod_perl. In both cases, Passenger tries to serve the mod_perl app and tells me it can't find the correct files. Anyone know what I'm doing wrong?
Here's my setup atm:
NameVirtualHost *:80
RailsAutoDetect off
<VirtualHost *:80>
DocumentRoot (home of rails app)/public
RailsBaseURI /
</VirtualHost>
PerlModule Apache::DBI
PerlRequire /opt/rt3/bin/webmux.pl
Alias /rt /opt/rt3/share/html <== mod_perl app
<Location /rt>
AddDefaultCharset UTF-8
SetHandler perl-script
PerlHandler RT::Mason
</Location>
Well, for right now I've just set them up as two different VirtualHosts using different ports to connect. That works, but it's a little messy for my site to use and if anyone has a better idea, I'm all ears. Thanks.
Edit: Got it working! I ended up setting up two VirtualServers on different ports, then used mod-proxy to redirect traffic to the /rt site to the mod-perl VirtualServer (leaving the Passenger one as the default). This works great, and best of all my mod_perl site believes it's still in the same place as Passenger, which smooths out a lot of compatibility issues I was dealing with as well. I knew I was missing something simple! Just putting this up in case anyone else is having issues with this.