Bug #4608
closedCtrl-c to interrupt script causes hang and 100% cpu's core load
Description
=begin
I have got this bug after updating Ubuntu from 10.10 to 11.04 Beta.
Using shell commands like echo anything
causes hang and 100% cpu's core load, if during downloading a file you press ctrl-c to interrupt.
Without using shell commands all right, we get "^CInterrupted"
In the Ubuntu 10.10 all right.
For a wonder autotest have got the same problem after updating ubuntu to 11.04 Beta: if I press ctrl-c to close autotest it hangs and loads 100% cpu's core
roma@roma-comp:~/downloader$ ruby test.rb
Getting a file .. waiting for ctrl-c
^C^C^C
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
13159 roma 20 0 14052 8556 2568 R 100 0.4 1:52.68 ruby test.rb
I'm waiting for such a result:
roma@roma-comp:~/downloader$ ruby test.rb
Getting a file .. waiting for ctrl-c
^CInterrupted
=end
Files
Updated by ralovets (Roman Ralovets) over 13 years ago
=begin
This bug has been repeated on another computer with ubuntu 11.04 (ruby 1.9.2p180).
If using ruby 1.8.7 (2010-08-16 patchlevel 302) [i686-linux] it all works well.
=end
Updated by corny (Mr Corn) over 13 years ago
=begin
I have the same problem with a freshly installed Ubuntu 11.04 and ruby 1.9.2p180.
STRG-c works in irb-shell, but not in the rails shell. Same problem with autotest. No problems with ruby 1.8.7.
=end
Updated by MiiJaySung (Jason Earl) over 13 years ago
I filed a similar bug on Rail's lighthouse a few days ago too. I've found Natty in fact to be pretty bad in some areas regarding stablity, I really hope the Ubuntu team clean up the various issues soon (So anyone reading this, I suggest hold back from using Natty if you haven't installed it for a bit). I know the 2.6.38 kernel changed some scheduling bits, I'm not sure if this is what's triggering this.
This appears to be a process management / deadlock issue I think. If you manually install a kernel from Maverick (i.e. download the kernel + headers and use dpkg -i to install) it will prevent the issue, so this is a kernel change that has triggered this.
It takes a kill -9 to stop the process, so it's must be in some deadlock
Updated by kosaki (Motohiro KOSAKI) over 13 years ago
- Status changed from Open to Third Party's Issue
I think this is the same issue with Bug #4777.