rescue SignalException so rack apps can shutdown properly

[nicksoto]

When control-c'ing a rack app, WEBrick will not catch SIGINT and shutdown. Instead it hands back the following error:

ERROR Interrupt:
/Users/macbook/.rvm/rubies/ruby-1.9.3-p194/lib/ruby/1.9.1/webrick/server.rb:99:in `select'

[eregon]

You probably don't want to handle any signal by a shutdown, what about just rescuing top-level Interrupt?

[nicksoto]

thanks for your help eregon

[nicksoto]

woops

[eregon]

This should not be needed anymore, is it?

[eregon]

This behavior is mentioned in the documentation: http://www.ruby-doc.org/stdlib-1.9.3/libdoc/webrick/rdoc/WEBrick.html.
I guess the intent is to let to the user the freedom of handling SIGINT.

When I do a simple
ruby -rwebrick -e 'WEBrick::HTTPServer.new(Port: 8000, DocumentRoot: File.expand_path(".")).start' and Ctrl+C, it shutdowns (but the fatal message is shown, indeed):

[2012-11-17 19:41:31] FATAL Interrupt: 
    .../webrick/server.rb:120:in `select'
        ...
    -e:1:in `<main>'
[2012-11-17 19:41:31] INFO  going to shutdown ...
[2012-11-17 19:41:31] INFO  WEBrick::HTTPServer#start done.

If you want to change the default behavior or discuss it, you should open an issue at https://bugs.ruby-lang.org/.

[drbrain]

Yes, this behavior was changed since Ruby 1.9.3. WEBrick now shuts down on ^C

[nicksoto]

maybe a better illustration:

require 'rack'

class App
 def call(req)
   [200, {'Content-Type' => 'text/html'}, ['Hello! I Wont Exit Properly']]
 end
end
Rack::Handler::WEBrick.run App.new, :Port => 3000

this won't close, unless you do a kill -9. obviously not a major concern here, but thanks for the help again with this

[drbrain]

It quits as expected upon ^C without your patch, are you sure you tested it properly?

$ ruby t.rb 
[2012-11-17 15:15:28] INFO  WEBrick 1.3.1
[2012-11-17 15:15:28] INFO  ruby 2.0.0 (2012-11-15) [x86_64-darwin12.2.0]
[2012-11-17 15:15:28] INFO  WEBrick::HTTPServer#start: pid=10599 port=3000
^C[2012-11-17 15:15:29] FATAL Interrupt: 
    /usr/local/lib/ruby/2.0.0/webrick/server.rb:120:in `select'
    /usr/local/lib/ruby/2.0.0/webrick/server.rb:120:in `block in start'
    /usr/local/lib/ruby/2.0.0/webrick/server.rb:22:in `start'
    /usr/local/lib/ruby/2.0.0/webrick/server.rb:110:in `start'
    /Users/drbrain/tmp/gems/gems/rack-1.4.1/lib/rack/handler/webrick.rb:13:in `run'
    t.rb:8:in `<main>'
[2012-11-17 15:15:29] INFO  going to shutdown ...
[2012-11-17 15:15:29] INFO  WEBrick::HTTPServer#start done.
/usr/local/lib/ruby/2.0.0/webrick/server.rb:120:in `select': Interrupt
    from /usr/local/lib/ruby/2.0.0/webrick/server.rb:120:in `block in start'
    from /usr/local/lib/ruby/2.0.0/webrick/server.rb:22:in `start'
    from /usr/local/lib/ruby/2.0.0/webrick/server.rb:110:in `start'
    from /Users/drbrain/tmp/gems/gems/rack-1.4.1/lib/rack/handler/webrick.rb:13:in `run'
    from t.rb:8:in `<main>'

$ 

[nicksoto]

The ruby versions I tested with have different behavior. if ruby-1.9.3-p194, the app won't even close. If using 2.0, you will get the message above, albeit, with WEBrick sort of spilling its guts.

i thought it would make sense to bring the versions to have similar behavior, and have a one-line shutdown. instead of the fugly code above, just have:

[2012-11-17 20:18:28] INFO  WEBrick 1.3.1
[2012-11-17 20:18:28] INFO  ruby 2.0.0 (2012-11-18) [x86_64-darwin11.4.0]
[2012-11-17 20:18:28] INFO  WEBrick::HTTPServer#start: pid=65523 port=3000
^C[2012-11-17 20:18:30] INFO  going to shutdown ...
[2012-11-17 20:18:30] INFO  WEBrick::HTTPServer#start done.

as eregon pointed out, this is probably intentional so I can't argue really.

[drbrain]

In ruby, patches start against trunk then are backported to maintained branches if they are bug fixes. New features are not backported. If a bug fix has been applied to trunk but not a maintenance branch you can request that it be backported on http://bugs.ruby-lang.org. In order to be accepted to trunk they need to fix some bug in trunk or add some new feature to trunk. (New features submitted during the freeze will not be committed until after the next release.)

Before writing the patch please verify that the new feature is not present in trunk or that the bug still exists in trunk. If the bug has been fixed or the feature has been implemented since the last release the patch will be rejected. This will make everyone sad, and we don't want to waste your valuable efforts.

In this case, an equivalent change was made to trunk (https://github.com/ruby/ruby/blob/42d38dec/ChangeLog#L8993-L9003). As far as applying this patch is concerned, I don't see the need. WEBrick in trunk (where it matters as far as new patches are concerned) already behaves exactly as the subject and description of this patch say it doesn't.

If you think this is a bug that should be fixed in ruby 1.9.3 you can open a ticket to request that the original commits be backported to ruby 1.9.3 on http://bugs.ruby-lang.org.

Changing the behavior to shutdown on Interrupt or SignalException is a separate matter that would likely be considered a new feature and couldn't be backported to 1.9.3. I'm not the maintainer of WEBrick so I can't make this judgement.

If you think WEBrick should shutdown on Interrupt or SignalException please open a ticket on http://bugs.ruby-lang.org to be sure the WEBrick maintainer sees it. There's no need to repost the patch, you can simply link to this pull request on github.

I'm sorry we can't apply your contribution as a bug fix ☹ ☹ ☹