Thin does not obey QUIT / TERM signal under Ruby 1.9

Thx for the patch Nate!

Thanks for the super-quick commit! There's only one thing that's got me confused after re-re-reading the codebase.

There is this section of code that supposedly does the same thing, in lib/thin/server.rb:

protected
  # Register signals:
  # * INT calls +stop+ to shutdown gracefully.
  # * TERM calls <tt>stop!</tt> to force shutdown.    
  def setup_signals
    trap('QUIT') { stop }  unless Thin.win?
    trap('INT')  { stop! }
    trap('TERM') { stop! }
  end

But for some reason Ruby 1.9 does no likey.

So while my patch does indeed work, I'm concerned that it now changes the behavior for "QUIT" from graceful to "forceful" (eg, it bypasses stop which would wait for the backends to shutdown).

Perhaps this bit of code from Server#initialize doesn't work correctly?

  setup_signals unless options[:signals].class == FalseClass

Bottom line, I'm a little hesitant now about my patch. I'd like to understand "why" it works when Thin is already supposedly doing the same thing. Thoughts?

Thanks,
Nate

Seems the problem is that Ruby 1.9 is not trapping QUIT signal when daemonized. Works fine when not daemonized.

Yeah, I was going to ask about that. Both INT and QUIT are designed for terminal control, not daemon control:

http://en.wikipedia.org/wiki/Signal_(computing)

Note that QUIT is actually designed to dump core (and INT is Ctrl-C).

I think the more appropriate signals to use for daemon control would be TERM (rather than INT) for an immediate shutdown, and USR2 as opposed to QUIT for a graceful shutdown. USR1 is usually expected to do something like switch on verbose logging/etc, but I've seen other daemons use USR2 for a graceful restart or shutdown.

Alternatively, Thin could keep a counter of how many TERM signals it's received. When it receives the first one, it could initiate a soft shutdown via stop() and set "shutting_down = true" or whatever. If a second TERM is received (ie, "shutting_down" is already true) then stop! is immediately called. I've seen this pattern used a lot too. When I was a sysadmin I would always try kill twice then kill -9.

Hmmm, looks like Nginx, Unicorn, and Resque all use QUIT in the same fashion as Thin. So regardless of whether it's "right" or not (UNIX-ly speaking), maybe there's code in those daemons that works.

Hey Nate,
I think I fixed it in http://github.com/macournoyer/thin/commit/4028e2c8555079d59dd1260ce... can you give it a try plz.