Wednesday, January 2, 2008


Jan 02 - 08:41 GMT

When we activate fcgi in our .htaccess like given in your FAQ Examples then the sites won't work anymore.

Jan 02 - 08:47 GMT
Support - Mark

Hello Andreas,

Please provide us the exact URL and the error you are facing problem. In order to further investigate and assist you in a better way.

Kind regards,
Mark, Servage - Support
Servage Hosting

Jan 02 - 08:59 GMT

The site is meanwhile in production but only cgi and very slow as we were waiting ti get this problem solved since over 2 WEEKS

Please read the previous posts.
search simply for ruby and rails problems at servage and you get them all ;-)

It is affecting EACH domain running an RoR.

i.e. (That's the one in production since today running in cgi and it is Very very slow) - also running on cgi as fcgi is not working!

more will follow

TEAM 3 is ready for Redmine

We are proud to announce Redmine running on Servage Hosting. Redmine is a state of the art Project Management Tool which offers you lots of features. TEAM 3 will help you to set it up on Servage Hosting Accounts and any other Account. Contact us now!

Ruby on Rails fcgi - fastcgi NOT WORKING AT SERVAGE HOSTING

Jan 01 - 17:58 GMT
Hi it seems like your fcgi or fastcgi isn't working properly:

Try here:

It shows you a working Ruby on Rails Application.
Switching to fcgi/fastcgi will cause that the dispatch.fcgi won't get parsed. It will show up as text!!!

You can test tis when you change in www/biblio/.htaccess
RewriteRule ^$ index.html [QSA]
RewriteRule ^([^.]+)$ $1.html [QSA]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ dispatch.cgi [QSA,L]
#RewriteRule ^(.*)$ dispatch.fcgi [QSA,L]


RewriteRule ^$ index.html [QSA]
RewriteRule ^([^.]+)$ $1.html [QSA]
RewriteCond %{REQUEST_FILENAME} !-f
#RewriteRule ^(.*)$ dispatch.cgi [QSA,L]
RewriteRule ^(.*)$ dispatch.fcgi [QSA,L]

Line 32/33 .htaccess
RewriteRule ^$ index.html [QSA]
RewriteRule ^([^.]+)$ $1.html [QSA]
RewriteCond %{REQUEST_FILENAME} !-f
#RewriteRule ^(.*)$ dispatch.cgi [QSA,L]
RewriteRule ^(.*)$ dispatch.fcgi [QSA,L]

will display the ruby and rails application "biblio" and you can edit save ... with no problem

RewriteRule ^$ index.html [QSA]
RewriteRule ^([^.]+)$ $1.html [QSA]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ dispatch.cgi [QSA,L]
#RewriteRule ^(.*)$ dispatch.fcgi [QSA,L]

will display a text file (dispatch.fcgi)
# You may specify the path to the FastCGI crash log (a log of unhandled
# exceptions which forced the FastCGI instance to exit, great for debugging)
# and the number of requests to process before running garbage collection.
# By default, the FastCGI crash log is RAILS_ROOT/log/fastcgi.crash.log
# and the GC period is nil (turned off). A reasonable number of requests
# could range from 10-100 depending on the memory footprint of your app.
# Example:
# # Default log path, normal GC behavior.
# RailsFCGIHandler.process!
# # Default log path, 50 requests between GC.
# RailsFCGIHandler.process! nil, 50
# # Custom log path, normal GC behavior.
# RailsFCGIHandler.process! '/var/log/myapp_fcgi_crash.log'
require File.dirname(__FILE__) + "/../config/environment"
require 'fcgi_handler'


in comparison dispatch.cgi looks like this:

require File.dirname(__FILE__) + "/../config/environment" unless defined?(RAILS_ROOT)

# If you're using RubyGems and mod_ruby, this require should be changed to an absolute path one, like:
# "/usr/local/lib/ruby/gems/1.8/gems/rails-0.8.0/lib/dispatcher" -- otherwise performance is severely impaired
require "dispatcher"

ADDITIONAL_LOAD_PATHS.reverse.each { |dir| $:.unshift(dir) if } if defined?(Apache::RubyRun)
NOTE: I switched to cgi mode in .htaccess
as fcgi isn't working at all.
Could you please check why fcgi isn't working and let's dispatch.fcgi not parsed and upshowing as text file? Thanks!

Please Check all Ruby on Rails applications we tested with the same problem. None of them is working in fcgi mode (/1_redmine - REDMINE) (/www/TYPO_rails - TYPO - Typosphere) (/www/biblio - Test Case to locate the problem why no ror is working on servage hosting)

Jan 01 - 18:21 GMT

Hi Servage
YIPPI It is working but only with CGI!!

So please check fcgi - somethings seems to be wrong here in your server configuration:

I got Redmine Working using cgi instead of fcgi.
I copied the settings from our biblio example to redmine

Then it was working

In other words something seems to be wrong with your fcgi and this was holding us up now since over 2 weeks!!! and delayed our progress a lot!

I hope you can fix the fcgi problem in the next 8 hours (our night here - but your day!) We will check tomorrow as like you write in your faq fcgi is 10times faster then cgi

CU Andi

Jan 02 - 03:52 GMT

ANY NEWS on the FCGI Front as ruby on rails is still not working with fcgi on SERVAGE HOSTING and therefore pretty slow


Difficult Question as the first thing which needs realy to be changes is the SUPPORT at all. Fire all of them and try to work together with a professional SUPPORT CENTER > OUTSOURCE these activities to profis if you don't have own ones available. The one SERVAGE HOSTING has at the moment is not at all acceptable!
But this will be another Thread:
We will list here some small things which would make life at SERVAGE HOSTING much easier:
  1. Insert a reload bottom into your filemanager
  2. Add a ZIP/TarGZ Functionality to the filemanager to pack folders and files (i.e. for backup)
  3. Add a COPY and PASTE functionality to the filemanager
  1. The Virtual Hosts of xyz are not sorted which makes managing very difficult if you have a TEST website i.e. with 100 of sub domains. They should be sorted 0-9-A-Z
  2. Creating a subdomain is fast but it won't be active for hours / perhaps even days!!! this is incredible for any production, test or development site
  1. All Databases should be sorted in a list 0-9-a-z in all views!
  2. The standard collation should be set to utf-8-unicode-ci instead the now existing latin-swedish-ci
    Until now you always need to switch to phpmyadmin before inserting any data into your databases to switch them to utf-8 otherweise they are latin1
    Actually it would be OK to have this process:
    1. Create a new database
    2. Add a field which asks for the collation utf8-unicode-ci
    3. execute the sql querie to achieve the utf-8 settings
    Then no additional accessing of phpmyadmin would be necessary
  1. Drupal is running only on MYSQL 4 Mode
  2. Joomla is running only on MYSQL 4 Mode

This post will be continued and updated - so stay tuned!