Can't stop Thin

[nyarly]

Listening on 0.0.0.0:8081, CTRL+C to stop
^CStopping ...
^CStopping ...
^C^CStopping ...
Stopping ...
^C^C^C^C^CStopping ...
Stopping ...
Stopping ...
Stopping ...
Stopping ...

Have to ^Z and kill -9 %1. Which is suboptimal.

[amoghe]

Could you provide the command line invocation which causes this?

[nyarly]

I'm using it here: https://github.com/nyarly/rhet-butler

Specifically: https://github.com/nyarly/rhet-butler/blob/master/lib/rhet-butler/web/main-app.rb#L140

[amoghe]

From a quick glance at the gist it seems like you are instantiating the Thin::Server and running it in your own EM reactor.

This issue is a dup of #177

In your case (from the gist you provided) seems like you want to run a Thin::Server (i.e. - there isnt an option to run any other server). If that is true, then why not instantiate a Thin::Server and #run it directly? (There is no need to go via the Rack::Hander.get interface. (Please correct me if I missed something).

[amoghe]

Seeing as how #177 is pretty long, I'll post the short version here:

When run on its own, Thin::Server owns the EM reactor loop. However, when the user starts the Thin::Server within his/her own reactor, Thin::Server does not "own" it (since it may be running alongside other servers in the reactor). So on shutdown Thin::Server cannot (and should not) terminate the reactor loop. If your intent is to only run the Thin::Server, then let it own the reactor, and it'll handle signals and terminate correctly. Else you should handle the signal and deal with the shutdown process in your code (by shutting down individual servers in the reactor, and then terminating the reactor loop).

[nyarly]

Seems like some first-class docs of this would be worthwhile. I'm running Thin alongside SockJS, which itself needs to use the reactor (although it gets mounted under Thin, so maybe the one could hang off of the other...)

SockJS is also why a) we only use Thin and b) it's as a Rack lookup - I'd like in the future to make it more flexible, since I've had reports that Thin has given some people problems.

I'll look into an approach that handles the signal myself - is there a way to get Thin to not trap INT? (Or not get Thin to...) ?

[amoghe]

I apologize but Im not familiar with SocksJS. From your code it seems like it is part/core of the rack app that is passed to thin. In this case (I presume) sockjs is a rack compatible app (and need not know about the EM reactor).

There are two options here:

• The Rack::Handler::Thin#run method takes an options hash which it passes onto the Thin::Server. You could pass :signals => false (so that thin doesnt handle signals), and handle them yourself.
• Seeing as how thin is the only server running in the EM reactor, you could (as mentioned before) instantiate the Thin::Server directly and #start! it in your code (so it owns the reactor and does its default signal handling, which is sufficient for shutting down on Ctrl+C).

[amoghe]

Seems like some first-class docs of this would be worthwhile.

Agreed. Currently most (all?) of the documentation covers running(/administering) Thin as a standalone server. Very little documentation exists for embedding thin (server) into existing applications. Most folks are forced to read the src (which is not a bad thing, really). Maybe @macournoyer has thoughts on a new section for this?

[macournoyer]

Sorry for the late reply.

Yes I need to update the doc on the website. But it should all be documented in the comments here: https://github.com/macournoyer/thin/blob/master/lib/thin/server.rb. If something is missing let me know or submit a PR.