New release of SCGI

It’s been almost two years since the last release of Zed S.'s SCGI
Rails Runner (0.4.3 in October 2005). I’ve been using it in production
since then and have modified it to add some new features and remove some
ones I wasn’t using. Zed has allowed me to take over the project, and
I’ve just released a new version of it (0.6.0). Here’s a summary of the
changes:

  • Single-port clustering is back
  • scgi_ctrl is fully configurable on the command line
  • Clustering and processing are now built into scgi_ctrl
  • DRb, Win32, and throttling are no longer supported
  • Soft reconfiguration is no longer supported (no SIGUSR1)
  • Restarting via SIGHUP is no longer supported (SIGHUP is the same as
    SIGINT)
  • The only commands available to scgi_ctrl are start and stop

Here’s an list of the available options and defaults:

scgi_ctrl [option=value, …] (start|stop)
Options:
-b, --bind IP address to bind to [127.0.0.1]
-c, --config Location of config file [config/scgi.yaml]
-d, --directory Working directory [.]
-e, --environment Environment (for Rails) [production]
-f, --fork Number of listners on each port [1]
-l, --logfile Location of log file [log/scgi.log]
-m, --maxconns Maximum number of concurrent users [2**30-1]
-n, --number Number of ports to bind to [1]
-p, --port Starting port to bind to [9999]
-P, --pidfile Location of pid file [log/scgi.pid]
-r, --processor Type of processor to use [Rails]

To try it out:

sudo gem install scgi

The RubyForge project is located at http://rubyforge.org/projects/scgi/.

Enjoy,
Jeremy

Hi,

Looking at using the updated scgi gem version. I have a bit of confusion
regarding how to run it. The earlier Zed version(0.4.3) ran without
issue in a lightty configuration I have, pre 2.+ ROR. Updated to 2.1.1
and the scgi_service command fails due to method missing errors which
makes believe .0.4.3 and ROR 2.1.1 are not compatible.

If I upgrade to gem scgi .0.9.0 will it run with ROR 2.1.1?

If so, should the scgi_rails(0.4.3) gem be removed? I tried doing just
that and the scgi_ctrl command was not found.

I am looking for the steps to use the new SCGI gem. Sorry if this is a
bit brain dead, I have tried several combinations without success, any
help is appreciated.

thanks,
Rick

Rick F. wrote:

Hi,

Looking at using the updated scgi gem version. I have a bit of confusion
regarding how to run it. The earlier Zed version(0.4.3) ran without
issue in a lightty configuration I have, pre 2.+ ROR. Updated to 2.1.1
and the scgi_service command fails due to method missing errors which
makes believe .0.4.3 and ROR 2.1.1 are not compatible.

If I upgrade to gem scgi .0.9.0 will it run with ROR 2.1.1?

If so, should the scgi_rails(0.4.3) gem be removed? I tried doing just
that and the scgi_ctrl command was not found.

I am looking for the steps to use the new SCGI gem. Sorry if this is a
bit brain dead, I have tried several combinations without success, any
help is appreciated.

thanks,
Rick

The command line tool is now called style and it is available in the
ruby-style gem [1] (this is mentioned in the ruby-scgi README). The
reason for this is that the command line tool was generalized to support
multiple frameworks and backends. The ruby-style README has an example
configuration for Rails+SCGI.

[1] http://ruby-style.rubyforge.org/

Jeremy

Thanks Jeremy.

I am up and running on my Linux box per your direction but I noticed
style on windows is not supported due to fork issues? Seems like SCGI on
windows with ROR 2.+ is not an option anymore?

Is there a solution for SCGI on windows with lighttpd and ROR 2.1.1?

Any info is appreciated?

Hi Jeremy,
Doesn’t appear to work even in debug mode on Windows. Let me know if you
need additional info or if I goofed up the testing.

Error below:

c:/ruby/lib/ruby/gems/1.8/gems/scgi-0.9.0/lib/scgi.rb:257:in trap': unsupported signal SIGHUP (ArgumentError) from c:/ruby/lib/ruby/gems/1.8/gems/scgi-0.9.0/lib/scgi.rb:257:insetup_signals’
from
c:/ruby/lib/ruby/gems/1.8/gems/ruby-style-1.2.1/lib/style/handler/scgi.rb:22:in
initialize' from c:/ruby/lib/ruby/gems/1.8/gems/ruby-style-1.2.1/lib/style/handler/scgi.rb:34:ininitialize’
from
c:/ruby/lib/ruby/gems/1.8/gems/ruby-style-1.2.1/lib/style/adapter/rails.rb:26:in
new' from c:/ruby/lib/ruby/gems/1.8/gems/ruby-style-1.2.1/lib/style/adapter/rails.rb:26:inrun_rails_scgi’
from
c:/ruby/lib/ruby/gems/1.8/gems/ruby-style-1.2.1/lib/style/adapter/rails.rb:8:in
run' from c:/ruby/lib/ruby/gems/1.8/gems/ruby-style-1.2.1/lib/style.rb:105:inload_adapter’
from
c:/ruby/lib/ruby/gems/1.8/gems/ruby-style-1.2.1/lib/style.rb:283:in
run_child' from c:/ruby/lib/ruby/gems/1.8/gems/ruby-style-1.2.1/lib/style.rb:291:inrun_in_foreground’
from
c:/ruby/lib/ruby/gems/1.8/gems/ruby-style-1.2.1/lib/style.rb:185:in
process' from c:/ruby/lib/ruby/gems/1.8/gems/ruby-style-1.2.1/bin/style:3 from c:/ruby/bin/style:19:inload’
from c:/ruby/bin/style:19

Rick F. wrote:

Thanks Jeremy.

I am up and running on my Linux box per your direction but I noticed
style on windows is not supported due to fork issues? Seems like SCGI on
windows with ROR 2.+ is not an option anymore?

Is there a solution for SCGI on windows with lighttpd and ROR 2.1.1?

Any info is appreciated?

It may run in debug mode (-D). This doesn’t fork or redirect io. You
are limited to running on one port, though. Give that a shot and
post/reply whether or not it works.

Thanks,
Jeremy

Rick F. wrote:

Hi Jeremy,
Doesn’t appear to work even in debug mode on Windows. Let me know if you
need additional info or if I goofed up the testing.

You didn’t goof anything up, it’s setting up the signals in scgi that is
the problem. Try this patch to ruby-scgi:

diff --git a/lib/scgi.rb b/lib/scgi.rb
index 8852da2…44200ce 100755
— a/lib/scgi.rb
+++ b/lib/scgi.rb
@@ -254,8 +254,13 @@ module SCGI
def setup_signals
trap(“TERM”) { @log.info(“SIGTERM, forced shutdown.”);
shutdown(force=true) }
trap(“INT”) { @log.info(“SIGINT, graceful shutdown started.”);
shutdown }

  •  trap("HUP") { @log.info("SIGHUP, graceful shutdown started."); 
    

shutdown }

  •  trap("USR2") { @log.info(status_info) }
    
  •  begin
    
  •    trap("HUP") { @log.info("SIGHUP, graceful shutdown started."); 
    

shutdown }

  •    trap("USR2") { @log.info(status_info) }
    
  •  rescue ArgumentError
    
  •    # Probably on Windows and these signals aren't supported
    
  •    nil
    
  •  end
    

    end

    Returns a Hash with status information. This is used

If this helps, I’ll put out a 0.9.1 ruby-scgi release.

Jeremy

Hi Jeremy,

This appears work however there is no way to cleanly shut down the

style --debug --handler scgi start

control-c’s are ignored and the only way to stop this is to shutdown /
close the cmd prompt.

Basically, I am surprised there is not a SIG handler in windows to do
this as well?

If more info is needed please let me know…

Thanks,
Rick

Rick F. wrote:

Hi Jeremy,

This appears work however there is no way to cleanly shut down the

style --debug --handler scgi start

control-c’s are ignored and the only way to stop this is to shutdown /
close the cmd prompt.

Basically, I am surprised there is not a SIG handler in windows to do
this as well?

If more info is needed please let me know…

Ctrl-C should send SIGINT, so I’m not sure why it is not working. You
should be able to stop it with Ctrl-Break. You may want to see what
Signal.list gives you, and try adding your own signal handlers to see if
you can get something that works better.

Jeremy