Impossible d’arrêter WEBrick 1.3.1 avec ctrl-c sur Ubuntu 11.04

J’utilise RVM, Ruby 1.9.2 et Rails 3.0.7

Une mise à mort standard du processus depuis un autre terminal ne fonctionne pas non plus, mais kill -9 le fait bien sûr.

J’ai trouvé une question similaire, CTRL + C au serveur Webbrick ignorée , mais il est difficile de savoir si cette question décrit le même problème sous-jacent. En outre, la résolution ne semble pas s’appliquer, car je n’utilise pas: git dans mon Gemfile.

mise à jour 1: (ancien maintenant … voir la mise à jour 2, ci-dessous, pour le vrai scoop)

J’ai réussi à réduire le problème à un seul bijou. Si vous générez le script de test suivant, vous pouvez également voir le problème (en supposant que vous êtes sur Ubuntu 11.04 … il n’y a eu aucun problème dans 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 

Le fait que le problème soit causé par l’interaction de Rails avec une gemme m’amène à penser que cette question est en réalité liée à CTRL + C au serveur Webbrick ignoré , bien que le scénario de test ci-dessus montre que git pour une gemme.

mise à jour 2:

Dans la mise à jour 1, j’ai mentionné que je l’ai réduit à une gemme. Lorsque j’ai parcouru ce joyau, j’ai finalement trouvé le véritable coupable. Le bijou faisait un appel système unique. J’ai apporté une modification mineure au script de test où je ne charge plus le joyau de barista, mais j’ajoute simplement un appel système unique à la fin de l’application.rb. Avec cet appel système, ctrl-c ne fonctionne pas. Supprimez l’appel système et cela fonctionne.

 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 

Cela pourrait expliquer la ressemblance apparente entre cette question et CTRL + C au serveur Webbrick ignoré . Mon intuition est que le joyau qu’ils mentionnent fait également un appel système.

Je préfère commenter que d’append une réponse à cela, mais pas assez de rep.

J’ai le même problème et j’ai constaté que la reprise (avec fg ) après avoir tapé ctrlc puis une pause (avec ctrlz , comme proposé ci-dessus) fait l’affaire.

Donc, la recette est la suivante:

  1. ctrlc (ne fait rien tout de suite)
  2. ctrlz (interrompt WEBrick, retourne au shell)
  3. fg (reprend WEBrick, suivi immédiatement avec SIGINT)

     lampadmin@lampadmin-DX4840:/var/www/rails/agences$ rs => 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, puis 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 

J’ai un problème similaire, j’ai utilisé Ctrl + Z pour mettre le travail en pause, puis je kill -9 %1 pour tuer le premier travail en pause. Manière détournée de le tuer, mais ça marche.

Voir cette question sur le super utilisateur pour plus d’informations: https://superuser.com/questions/243460/what-to-do-when-ctrl-c-cant-kill-a-process

Je crois que ^C ne peut pas tuer les serveurs WEBrick car le serveur crée une nouvelle session:

Dans 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 

(Il existe un code très similaire dans rack/server.rb , donc si vous démarrez WEBrick via un rack, vous pouvez laisser les options de ligne de commande -D ou --daemonize .)

Et à partir de la page de 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. 

n’a pas de contrôle tty signifie que les signaux générés par un terminal ( ^Z SIGTSTP , ^\ SIGKILL , SIGTTIN , SIGTTOU , etc.) ne peuvent pas atteindre le processus même s’il avait été démarré sur ce terminal. Le lien a été coupé.

Ok, le problème a été résolu pour moi. Une mise à jour récente du kernel, que j’ai appliquée dans le cadre des mises à jour standard d’Ubuntu, a résolu le problème.

En outre, voici une bonne discussion sur le problème, qui explique que la cause principale était une régression du kernel introduite dans 2.6.38 ( http://redmine.ruby-lang.org/issues/4777 )

La régression a été corrigée et il semble que le correctif ait récemment été intégré aux mises à jour d’Ubuntu. Par conséquent, si vous êtes concerné par ce problème, vous devez appliquer les dernières mises à jour.

Cela se produit également pour moi sur Mac OS X.

Étonnamment, ni Rack ni WEBrick ne mettent en place des gestionnaires de signaux personnalisés. Je mets ceci dans la méthode d’ call de mon application rack et il me dit que le gestionnaire DEFAULT pour SIGINT est le gestionnaire actuel (renvoie la chaîne "DEFAULT" ):

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

Je soupçonne que quelque chose se passe dans Ruby qui select les signaux.

Voici deux façons d’arrêter le serveur:

1) Appuyez sur ctrl-z pour suspendre. Ensuite, kill -ABRT pid_or_job_id . Je ne sais pas comment le processus se déroule bien. C’est gênant mais vous n’avez pas à append de code.

2a) Si vous utilisez Rack, ajoutez-le juste avant d’appeler Rack::Handler::WEBrick.run :

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

2b) Si vous utilisez de la vanille WEBrick :

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

server est votre object serveur WEBrick .

C’est bon si vous utilisez souvent SIGINT . Vous souhaiterez peut-être également append des gestionnaires pour TERM et HUP .

utilisé cette ligne pour créer un raccourci avec ccsm (gestionnaire de parameters de configuration ou smth comme ça) -> commandes:

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

mettre à (ctrl + shift + `) ou quelque chose que vous aimez

J’ai eu le même problème lors de la mise à jour de mon Ubuntu. Impossible de quitter normalement webrick en utilisant Ctrl + C , a dû utiliser kill -9

J’ai moi-même rencontré ce problème. J’utilise rmv rails 3.0.9 et ubuntu 11.04 32bit running Unité. J’ai trouvé que le terminateur passera le Ctrl + c aux rails.

Semble être un problème avec Unity et Terminal, le ^ c n’est pas traité correctement pour une raison quelconque. essayez de faire la même chose avec terminator (un meilleur terminal). Ou utilisez simplement gnome.

C’est du moins comme ça que j’ai résolu le problème. Je propose que nous passions ceci à askubuntu.com.

Dans U10.04, j’ai eu ce problème avec webrick, mongrel, console, sqlite, peu importe ce que je courais.

Ma dernière réponse a été supprimée, je ne sais pas pourquoi, mais je réessaie car je pense vraiment que cela est très lié au problème.

Dans mon Gemfile, je n’ai qu’un seul joyau qui utilise l’argument: git.

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

J’ai le même problème pour vous tous, ctrl + C est ignoré; mais si je supprime cette dépendance de gem, (et je supprime l’initialiseur associé) le problème est parti et je peux utiliser ctrl + c comme avant.

Je pourrais penser que c’est un bug lié à rails_admin gem mais comme je l’ai lu dans cette autre question: CTRL + C au serveur Webbrick a ignoré son plus susceptible d’être lié à n’importe quelle gem dans laquelle le paramètre: git est utilisé …

J’espère que c’est utile.

Trouvé une sorte de solution. Run in terminal:

 stty -echoctl 

Et puis Ctrl-C fonctionnera. http://linux.m2osw.com/remove-ctrl-C-from-being-printed-in-console

Travaillé juste pour une session. Publié meilleure solution près.

Expérience intéressante (et bonne solution pour les prochaines semaines):

Si vous êtes sous Ubuntu et que vous utilisez Guake pour un access rapide au terminal, vous pouvez lancer

 rails s 

Là. Ctrl + C fonctionne de manière reproductible là pour moi et arrête le serveur.

J’espère que je pourrais aider! 🙂

EDIT: Comme ce n’est évidemment pas reproductible pour tout le monde, voici ma configuration: Ubuntu 11.04, 32-bit, Guake 0.4.2-4ubuntu1

Si ctr + c ne fonctionne pas, alors avant d’aller implémenter les méthodes mentionnées, affichez simplement les parameters de votre terminal. Parfois, il peut arriver que nous changions les raccourcis clavier du terminal en fonction de nos besoins. Et nous assignons ctr + c pour copier le contenu du terminal. Dans ce cas, ctr + c ne fonctionnera pas pour arrêter le serveur, mais sera utilisé comme copie.

Si les parameters ne sont pas modifiés, essayez d’utiliser un autre port comme 4000.