Can't stop WEBrick 1.3.1 with ctrl-c on Ubuntu 11.04

雨燕双飞 提交于 2019-11-27 19:00:50
StrangeElement

I'd rather comment than add an answer for this, but not enough rep.

I have the same issue and found that resuming (with fg) after typing ctrl-c then pausing (with ctrl-z, as offered above) does the trick.

So the recipe is:

  1. ctrl-c (does nothing right away)
  2. ctrl-z (pauses WEBrick, goes back to shell)
  3. fg (resumes WEBrick, immediately follow through with SIGINT)

    lampadmin@lampadmin-DX4840:/var/www/rails/agences$ r s
    => Booting WEBrick
    => Rails 3.0.5 application starting in development on http://0.0.0.0:3000
    => Call with -d to detach
    => Ctrl-C to shutdown server
    [2011-05-14 14:25:36] INFO  WEBrick 1.3.1
    [2011-05-14 14:25:36] INFO  ruby 1.9.2 (2011-02-18) [x86_64-linux]
    [2011-05-14 14:25:36] INFO  WEBrick::HTTPServer#start: pid=2585 port=3000
    

    ^C^Z (<-- ctrl-c, then ctrl-z)

    [1]+  Stopped                 rails s
    lampadmin@lampadmin-DX4840:/var/www/rails/agences$ fg
    rails s
    [2011-05-14 14:25:45] INFO  going to shutdown ...
    [2011-05-14 14:25:45] INFO  WEBrick::HTTPServer#start done.
    Exiting
    
Jamie Penney

I'm having a similar problem, have been using Ctrl+Z to pause the job, then kill -9 %1 to kill the first paused job. Roundabout way of killing it, but it works.

See this question on Superuser for more info: https://superuser.com/questions/243460/what-to-do-when-ctrl-c-cant-kill-a-process

I believe ^C can't kill WEBrick servers because the server creates a new session:

In webrick/server.rb:

  class Daemon
    def Daemon.start
      exit!(0) if fork
      Process::setsid
      exit!(0) if fork
      Dir::chdir("/")
      File::umask(0)
      STDIN.reopen("/dev/null")
      STDOUT.reopen("/dev/null", "w")
      STDERR.reopen("/dev/null", "w")
      yield if block_given?
    end
  end

(Very similar code exists in rack/server.rb, so if you're starting WEBrick via rack, you might want to leave off the -D or --daemonize command line options.)

And from the setsid(2) manpage:

   setsid() creates a new session if the calling process is not
   a process group leader.  The calling process is the leader of
   the new session, the process group leader of the new process
   group, and has no controlling tty.

has no controlling tty means that signals generated by a terminal (^Z SIGTSTP, ^\ SIGKILL, SIGTTIN, SIGTTOU, etc.) can't reach the process even if it had been started on that terminal. The link has been severed.

Ok, the issue has been resolved for me. A recent kernel update, which I applied as part of Ubuntu's standard updates, fixed the problem.

Also, here is a good discussion of the issue, which explains that the root cause was a kernel regression introduced in 2.6.38 ( http://redmine.ruby-lang.org/issues/4777 )

The regression was patched, and it looks like the patch recently made it into Ubuntu's updates, so if you're being affected by this issue, you should apply the latest updates.

This is also happening for me on Mac OS X.

Surprisingly, neither Rack or WEBrick is setting up custom signal handlers. I put this in my rack app's call method and it's telling me that the DEFAULT handler for SIGINT is the current one (returns the String "DEFAULT"):

p Signal.trap('INT', 'DEFAULT')

I suspect that something's going on in ruby's select that's trapping the signals.

Here's are 2 ways to stop it the server:

1) Press ctrl-z to suspend. Then kill -ABRT pid_or_job_id. I don't know how "cleanly" the process exits though. This is annoying but you don't have to add any code.

2a) If you're using Rack, add this right before you call Rack::Handler::WEBrick.run:

Signal.trap('INT') {
  Rack::Handler::WEBrick.shutdown
}

2b) If you're using vanilla WEBrick:

Signal.trap('INT') { server.shutdown }

where server is your WEBrick server object.

These are good if you're going to be using SIGINT often. You may want to add handlers for TERM and HUP also.

used this line to create shortcut with ccsm (compiz conig settings manager or smth like this) -> commands:

kill -9 `pgrep -fl 'script/rails s' | awk '{print $1}'`

set to (ctrl+shift+`) or anything you like

Nicolas Blanco

I had the same problem when updating my Ubuntu. Impossible to quit normally webrick using Ctrl+C, had to use kill -9...

alley

I ran into this problem myself. I am using rvm rails 3.0.9 and ubuntu 11.04 32bit running unity. I found that terminator will pass the Ctrl+c to rails.

Seems to be a problem with Unity and Terminal the ^c is not processed correctly for some reason. try doing the same thing using terminator (a better terminal). Or just use gnome.

At least this is how I resolved the problem. I propose we move this to askubuntu.com.

In U10.04 I had this problem running webrick, mongrel, console, sqlite, it didn't matter what I ran actually.

diegopau

My last answer was deleted don't know why but i try again cause i really think this is very related with the issue.

In my Gemfile I have only one gem which is using the argument :git.

gem 'rails_admin', :git => 'git://github.com/sferik/rails_admin.git'

I have the same issue af all of you, ctrl+C is ignored; but if i delete this gem dependency, (and I delete de related initializer) the issue is gone and i can use ctrl+c as before.

I could think it is a bug related with rails_admin gem but as I read in this other question: CTRL+C to Webbrick server ignored its more likely to be related with any gem in which the :git parameter is used...

Hope its helpful.

Found some kind of solution. Run in terminal:

stty -echoctl

And then Ctrl-C will work. http://linux.m2osw.com/remove-ctrl-C-from-being-printed-in-console

Worked just for one session. Posted better solution near.

Dorian

Interesting experience (and good workaround for the next weeks):

If you are under Ubuntu and use Guake for quick terminal access, you can launch

rails s

there. Ctrl + C reproducibly works there for me and stops the server.

Hope I could help! :)

EDIT: As obviously this is not reproducibly for everyone, here is my setup: Ubuntu 11.04, 32-bit, Guake 0.4.2-4ubuntu1

If ctr+c is not working, then before going to implement the methods mentioned , just see your terminal settings. Sometimes it may happen that we change the shortcut keys of terminal as our convenience. And we assign ctr+c for copying content of terminal. In this case ctr+c wont work for stopping the server, instead it will be used as copy purpose.

If the settings are not changed then try using another port like 4000.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!