Не могу остановить WEBrick 1.3.1 с помощью Ctrl-C в Ubuntu 11.04

Question

Я использую RVM, Ruby 1.9.2 и Rails 3.0.7

Стандартное уничтожение процесса из другого терминала тоже не работает, но, конечно, kill -9 делает.

Я нашел похожий вопрос, CTRL + C на сервере Webbrick проигнорировал , но неясно, описывает ли этот вопрос ту же самую основную проблему. Кроме того, разрешение, кажется, не применяется, так как я не использую: git в моем Gemfile.

обновление 1: (старое сейчас ... см. Обновление 2, ниже, для реального совка)

Мне удалось сузить вопрос до одного драгоценного камня. Если вы используете следующий тестовый скрипт, вы также можете увидеть проблему (при условии, что вы работаете в Ubuntu 11.04 ... в 10.04 проблемы не было)

rm -rf tmpkilltest

rvm 1.9.2
rvm --force gemset delete tmpkilltest
rvm gemset create tmpkilltest
rvm 1.9.2@tmpkilltest

gem install rails -v=3.0.7 --no-rdoc --no-ri
gem install sqlite3 -v=1.3.3 --no-rdoc --no-ri

rails new tmpkilltest

cd tmpkilltest

echo "gem 'barista', '1.0'" >> Gemfile

bundle

rails s

Тот факт, что проблема вызвана взаимодействием Rails с гемом, заставляет меня поверить, что этот вопрос на самом деле связан с CTRL + C для сервера Webbrick, игнорируемого , хотя тестовый пример выше показывает, что этот явно не вызван использованием: git для драгоценного камня.

обновление 2:

В обновлении 1 Я упоминал, что сузил его до жемчужины. Когда я прошел этот драгоценный камень, я в конечном итоге нашел настоящего преступника. Драгоценный камень делал один системный вызов. Я сделал очень незначительную модификацию тестового скрипта, где я больше не загружаю гем бариста, а просто добавляю один системный вызов в конце application.rb. С этим системным вызовом ctrl-c не работает. Удалите системный вызов, и он работает.

rm -rf tmpkilltest

rvm 1.9.2
rvm --force gemset delete tmpkilltest
rvm gemset create tmpkilltest
rvm 1.9.2@tmpkilltest

gem install rails -v=3.0.7 --no-rdoc --no-ri
gem install sqlite3 -v=1.3.3 --no-rdoc --no-ri

rails new tmpkilltest

cd tmpkilltest

bundle

echo "\`date\`" >> config/application.rb

rails s

Это может объяснить кажущееся сходство между этим вопросом и CTRL + C на сервере Webbrick, игнорируемом . Я догадываюсь, что камень, о котором они говорят, также делает системный вызов.

Answer 1

Я бы лучше прокомментировал, чем добавил ответ, но недостаточно реп.

У меня та же проблема, и я обнаружил, что возобновление (с fg) после ввода ctrl - c затем приостановка (с ctrl - z , как предложено выше) делает свое дело.

Итак, рецепт:

1. ctrl - c (сразу ничего не делает)
2. ctrl - z (пауза WEBrick, возвращается в оболочку)

3. fg (возобновляет WEBrick, немедленно выполните 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, затем ctrl-z) </p>

   [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
   

Answer 2

У меня похожая проблема, я использовал Ctrl + Z , чтобы приостановить задание, затем kill -9 %1, чтобы убить первое приостановленное задание. Окольный способ убить его, но это работает.

См. Этот вопрос на Superuser для получения дополнительной информации: https://superuser.com/questions/243460/what-to-do-when-ctrl-c-cant-kill-a-process

Answer 3

Хорошо, проблема была решена для меня. Недавнее обновление ядра, которое я применил как часть стандартных обновлений Ubuntu, устранило проблему.

Кроме того, здесь хорошее обсуждение проблемы, которая объясняет, что основной причиной была регрессия ядра, представленная в 2.6.38 (http://redmine.ruby -lang.org / Issues / 4777 )

Регресс был исправлен, и похоже, что этот патч недавно вошел в обновления Ubuntu, поэтому, если вы подвержены этой проблеме, вам следует применить последние обновления.

Answer 4

Я считаю, ^C не может убить серверы WEBrick, потому что сервер создает новый сеанс:

В 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

(Очень похожий код существует в rack/server.rb, поэтому, если вы запускаете WEBrick через стойку, вы можете не использовать параметры командной строки -D или --daemonize.)

А из справочной страницы setsid(2):

   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.

не имеет контроля tty означает, что сигналы, генерируемые терминалом (^Z SIGTSTP, ^\ SIGKILL, SIGTTIN, SIGTTOU и т. Д.), Не могут быть достигнуты процесс, даже если он был запущен на этом терминале. Ссылка разорвана.

Answer 5

Это также происходит со мной в Mac OS X.

Удивительно, но ни Rack, ни WEBrick не настраивают пользовательские обработчики сигналов. Я поместил это в метод call моего стоечного приложения, и он говорит мне, что обработчик DEFAULT для SIGINT является текущим (возвращает String "DEFAULT"):

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

Я подозреваю, что что-то происходит в select Рубина, который захватывает сигналы.

Вот 2 способа остановить его на сервере:

1) Нажмите Ctrl-Z для приостановки. Тогда kill -ABRT pid_or_job_id. Я не знаю, как «чисто» процесс выходит, хотя. Это раздражает, но вам не нужно добавлять код.

2a) Если вы используете Rack, добавьте это прямо перед вызовом Rack::Handler::WEBrick.run:

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

2b) Если вы используете ваниль WEBrick:

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

где server - ваш WEBrick объект сервера.

Это хорошо, если вы собираетесь часто использовать SIGINT. Вы также можете добавить обработчики для TERM и HUP.

Answer 6

использовал эту строку для создания ярлыка с помощью ccsm (менеджер настроек compiz conig или что-то в этом роде) -> команды:

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

установить в (Ctrl + Shift + `) или что-нибудь вам нравится

Answer 7

Я столкнулся с этой проблемой сам. Я использую рельсы Rvm 3.0.9 и Ubuntu 11.04 32bit работает Unity. Я обнаружил, что терминатор будет передавать Ctrl + c на рельсы.

Answer 8

У меня была такая же проблема при обновлении Ubuntu.Нельзя нормально выйти из вебрика с помощью Ctrl + C , пришлось использовать kill -9 ...

Answer 9

Если ctr + c не работает, то перед тем, как приступить к реализации упомянутых методов, просто посмотрите настройки вашего терминала.Иногда может случиться так, что для удобства мы меняем сочетания клавиш терминала.И мы назначаем ctr + c для копирования содержимого терминала.В этом случае ctr + c не будет работать для остановки сервера, вместо этого он будет использоваться в качестве цели копирования.

Если настройки не изменены, попробуйте использовать другой порт, например 4000.

Answer 10

Нашел какое-то решение. Запустить в терминале:

stty -echoctl

И тогда Ctrl-C будет работать. http://linux.m2osw.com/remove-ctrl-C-from-being-printed-in-console

Работал только на одну сессию. Выложено лучшее решение рядом.