Bug 472511 - [5.3] Ctrl-C Not Working in Kdump Initramfs Shell
[5.3] Ctrl-C Not Working in Kdump Initramfs Shell
Status: CLOSED CANTFIX
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kexec-tools (Show other bugs)
5.2
All Linux
low Severity low
: rc
: ---
Assigned To: Neil Horman
Martin Jenner
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-11-21 05:53 EST by CAI Qian
Modified: 2009-08-13 18:17 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-04-06 12:02:02 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description CAI Qian 2008-11-21 05:53:03 EST
Description of problem:
When dropping to a shell, Ctrl-C was not working. Since it was the only debug window available at this point, so there was almost not way to terminate a running command. As the result, it limits our ability to debug faulty system.

Version-Release number of selected component (if applicable):
Both kexec-tools-1.102pre-21.el5 and -50.el5

How reproducible:
always

Steps to Reproduce:
1. use the following kdump.conf to fall back on a shell.

ext3 <partition>
core_collector makedumpfile -nonexist
default shell

2. when dropping to a shell, run

sleep 60

3. Ctrl-C
  
Actual results:
Unable to terminate the command.

Expected results:
Should be able to terminate the command.

Additional info:
Ctrl-C worked fine in /bin/msh with a normal Linux kernel.
Comment 1 Neil Horman 2008-11-21 08:33:44 EST
do me a favor and tell me if the following command gets ctrl-c to work:
stty intr ^C
Thanks!
Comment 2 CAI Qian 2008-11-21 09:44:40 EST
It seems not work.

dropping to initramfs shell
exiting this shell will reboot your system
root:/> stty intr ^C
stty: intr requires an argument
C: not found

root:/> stty intr '^C'
root:/> stty -a
speed 115200 baud; rows 0; columns 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W;
lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
echoctl echoke
root:/> sleep 5
<unable to interrupt>
Comment 3 Neil Horman 2009-03-23 11:51:30 EDT
I'm reserving hp-sw9300-01 to try fix this
Comment 4 Neil Horman 2009-03-23 16:02:19 EDT
Cai, I was initially thinking that I needed to capture a controlling tty to fix this (and I still do think that), but even when I manually set that up, it still fails to work.  I'm wondering if conmux is somehow swallowing or mangling ctrl-c and other control characters.  Do you have a system with an honest to gooness serial port you can try this on?

Just drop to a shell in kdump and issue this command:
getty -l /bin/msh -n 115200 /dev/console

Thanks!
Comment 5 Neil Horman 2009-03-31 15:57:51 EDT
also, Cai, you may want to try issuing this command after you get a prompt
stty intr ^C
I cant remember if the interrupt character was set on the system I tried on.
Comment 6 CAI Qian 2009-04-01 07:52:13 EDT
I have tried to setup a serial console locally without using commux, but using "cu -l /dev/ttyS0 -n 19200". However, the Ctrl-C was still impossible to interrupt commands. Because it was an IA-64 box using 19200 serial speed, so I was running the following command,

root:/> getty -l /bin/msh -n 19200 /dev/console
<it output nothing...>

root:/> dd
<ctrl-c is not working anymore.>

root:/> stty intr ^C
stty: intr requires an argument
C: not found
<this command looks like give some errors.>

root:/> stty intr '^C'
<it output nothing if I quote ^C.>
Comment 7 Neil Horman 2009-04-06 11:45:49 EDT
The more I look at this the more I become convinced that this is a controlling tty issue, and one that we can't solve while we're operating on /dev/console.  I'll see if I can change mkdumprd to establish a controlling tty automatically during operation, but this might be a can'tfix at the moment.
Comment 8 Neil Horman 2009-04-06 12:02:02 EDT
yeah, I'm sorry, I'm doing some reading here, and busybox init (which needs to run to set the ttys up) can only be run from the kernel (can't exec it from /init), so I can't fix this without including the real /sbin/init, which I think is more bloat than its worth at the moment.  I'll try to get this into my mkdumprd rewrite, but I'm afraid this is cantfix for the current implementation
Comment 9 K Newman 2009-08-13 18:17:22 EDT
I just found this and figured I'd contribute this response.  If it isn't what you're looking for, I appologize.  To get an interactive shell using busybox so that you have a controlling tty (to make use of control-c), execute the following in the shell (note, you'll need the proper /dev entries of course):

/sbin/getty -l /bin/sh -n 38400 tty1

Note You need to log in before you can comment on or make changes to this bug.