ctrl-c not working in Rack::Handler::WEBrick

ctrl-c not working in Rack::Handler::WEBrick

[Stephen Bannasch]

After this commit:

   http://github.com/rack/rack/commit/e516d89ffcdad1c9d58432aaaff4a382ed3997e7

   commit <a href="/rack/rack/commit/e516d89ffcdad1c9d58432aaaff4a382ed3997e7">e516d89</a>
   Author: raggi <jftucker@gmail.com>
   Date:   Tue Mar 23 19:29:44 2010 +0000

       Move trap(:INT) to Rack::Server and support optional
       Handler protocol where handlers may implement .shutdown
       to do pre-exit cleanup.

CTRL-C no longer works to shut down webrick.

I've created an issue here: http://github.com/rack/rack/issues/#issue/35

Here's a trivial rack app with a webrick handler that shows the problem:

     require 'rack'
     app = proc do |env|
       [200, { 'Content-Type' => 'text/html' }, 'hello from rack and webrick']
     end
     server = ::Rack::Handler::WEBrick
     server.run app, :Port => 3002

Run this and try typing ctrl-c in the console:

     $ ruby hellorack.rb
     [2010-07-11 22:34:35] INFO  WEBrick 1.3.1
     [2010-07-11 22:34:35] INFO  ruby 1.9.1 (2010-01-10) [i386-darwin9.8.0]
     [2010-07-11 22:34:35] INFO  WEBrick::HTTPServer#start: pid=82455 port=3002
     ^C[2010-07-11 22:34:37] ERROR Interrupt:
       /Users/stephen/.rvm/rubies/ruby-1.9.1-p378/lib/ruby/1.9.1/webrick/server.rb:90:in `select'

An error is displayed but the program does not quit.

In this simple example the code at lib/rack/server.rb:208 is never executed and
no handler is actually registered for ctrl-c:

     trap(:INT) do
       if server.respond_to?(:shutdown)
         server.shutdown
       else
         exit
       end
     end

Rack::Handler instances don't appear to be related to Rack::Server instances.

Re: ctrl-c not working in Rack::Handler::WEBrick

[James Tucker]

Stephen, 

Please see my comments on the issue.

Handlers shouldn't contain traps, Rack::Server is responsible for that.

On 12 Jul 2010, at 03:48, Stephen Bannasch wrote:

> After this commit:
> 
>  http://github.com/rack/rack/commit/e516d89ffcdad1c9d58432aaaff4a382ed3997e7
> 
>  commit <a href="/rack/rack/commit/e516d89ffcdad1c9d58432aaaff4a382ed3997e7">e516d89</a>
>  Author: raggi <jftucker@gmail.com>
>  Date:   Tue Mar 23 19:29:44 2010 +0000
> 
>      Move trap(:INT) to Rack::Server and support optional
>      Handler protocol where handlers may implement .shutdown
>      to do pre-exit cleanup.
> 
> CTRL-C no longer works to shut down webrick.
> 
> I've created an issue here: http://github.com/rack/rack/issues/#issue/35
> 
> Here's a trivial rack app with a webrick handler that shows the problem:
> 
>    require 'rack'
>    app = proc do |env|
>      [200, { 'Content-Type' => 'text/html' }, 'hello from rack and webrick']
>    end
>    server = ::Rack::Handler::WEBrick
>    server.run app, :Port => 3002
> 
> Run this and try typing ctrl-c in the console:
> 
>    $ ruby hellorack.rb
>    [2010-07-11 22:34:35] INFO  WEBrick 1.3.1
>    [2010-07-11 22:34:35] INFO  ruby 1.9.1 (2010-01-10) [i386-darwin9.8.0]
>    [2010-07-11 22:34:35] INFO  WEBrick::HTTPServer#start: pid=82455 port=3002
>    ^C[2010-07-11 22:34:37] ERROR Interrupt:
>      /Users/stephen/.rvm/rubies/ruby-1.9.1-p378/lib/ruby/1.9.1/webrick/server.rb:90:in `select'
> 
> An error is displayed but the program does not quit.
> 
> In this simple example the code at lib/rack/server.rb:208 is never executed and
> no handler is actually registered for ctrl-c:
> 
>    trap(:INT) do
>      if server.respond_to?(:shutdown)
>        server.shutdown
>      else
>        exit
>      end
>    end
> 
> Rack::Handler instances don't appear to be related to Rack::Server instances.

Re: ctrl-c not working in Rack::Handler::WEBrick

[Alex Chaffee]

[-- Attachment #1: Type: text/plain, Size: 306 bytes --]

So to be clear (and to educate others who, like me, found this page after 
googling "rack webrick handler interrupt") -- when you want to invoke a Rack 
server programmatically, instead of 

Rack::Handler.default.run(app, options)

...the correct behavior is to use

Rack::Server.start(options)

...right?

[-- Attachment #2: Type: text/html, Size: 5146 bytes --]

Re: ctrl-c not working in Rack::Handler::WEBrick

[James Tucker]

[-- Attachment #1: Type: text/plain, Size: 380 bytes --]


On Jan 19, 2011, at 12:33 PM, Alex Chaffee wrote:

> So to be clear (and to educate others who, like me, found this page after googling "rack webrick handler interrupt") -- when you want to invoke a Rack server programmatically, instead of 
> Rack::Handler.default.run(app, options)
> ...the correct behavior is to use
> 
> Rack::Server.start(options)
> ...right?

Yes.

[-- Attachment #2: Type: text/html, Size: 5451 bytes --]

Re: ctrl-c not working in Rack::Handler::WEBrick

[Alex Chaffee]

[-- Attachment #1: Type: text/plain, Size: 618 bytes --]

On Thu, Jan 20, 2011 at 12:35 PM, James Tucker <jftucker@gmail.com> wrote:

>
> Yes.
>

Thanks for the concise reply! :-)

I did a little more research and it turns out that there's a bug in Rack
1.2.1 whereby the ":app" option is ignored; that may explain why some people
(e.g. the Jasmine gem, where I found the control-C bug) are using the less
correct Handler invocation. It's been fixed on HEAD but not pushed; any idea
when 1.2.2 will be released?

 - A


-- 
Alex Chaffee - alex@stinky.com - http://alexch.github.com
Stalk me: http://friendfeed.com/alexch | http://twitter.com/alexch |
http://alexch.tumblr.com

[-- Attachment #2: Type: text/html, Size: 1355 bytes --]

Re: ctrl-c not working in Rack::Handler::WEBrick

[James Tucker]

[-- Attachment #1: Type: text/plain, Size: 823 bytes --]


On Jan 21, 2011, at 10:56 AM, Alex Chaffee wrote:

> On Thu, Jan 20, 2011 at 12:35 PM, James Tucker <jftucker@gmail.com> wrote:
> 
> Yes.
> 
> Thanks for the concise reply! :-)
> 
> I did a little more research and it turns out that there's a bug in Rack 1.2.1 whereby the ":app" option is ignored; that may explain why some people (e.g. the Jasmine gem, where I found the control-C bug) are using the less correct Handler invocation. It's been fixed on HEAD but not pushed; any idea when 1.2.2 will be released?

When I or one of the other team members have time. At the moment there's some outstanding patch backlog that requires careful checking because it's basically flipping some opinions back and forward, and those things need to be resolved in a way that the patches stop coming in every other release.

[-- Attachment #2: Type: text/html, Size: 1449 bytes --]