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.
do me a favor and tell me if the following command gets ctrl-c to work: stty intr ^C Thanks!
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>
I'm reserving hp-sw9300-01 to try fix this
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!
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.
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.>
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.
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
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