Customized Linux systems cannot use crtl+c to terminate ping commands?

Question

I customized the root file system using Busybox， and its version is 1.36.1. I don't know why my device cannot be terminated by ctrl+c when typing ping an IP on the monitor keyboard. However, when I connect to the device through SSH, the ping an IP can be terminated by ctrl+c? The same goes for ctrl+u.

I referred to similar problems, but did not solve my problem.

By the way, my system does not have a desktop environment. My processor is Intel x86_64 bit.

#1 #stty -a (SSH connection)

speed 38400 baud; rows 41; columns 143; line = 0;
intr = ^C; quit = ^\; erase = ^H; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z;
rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd -cmspar cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc ixany -imaxbel iutf8
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 -flusho -extproc

#stty -a (monitor keyboard)

speed 38400 baud; rows 37; columns 100; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd -cmspar cs8 hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl -ixon -ixoff
-iuclc -ixany -imaxbel iutf8
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 -flusho -extproc

#2 #cat /etc/inittab (old)

::sysinit:/etc/init.d/rcS
::respawn:-/bin/sh
::ctrlaltdel:/bin/umount -a -r
::shutdown:/bin/umount -a -r
::shutdown:/sbin/swapoff -a

#cat /etc/inittab （new）

::sysinit:/etc/init.d/rcS
tty1::respawn:/sbin/getty 38400 tty1
tty2::respawn:/sbin/getty 38400 tty2
tty3::respawn:/sbin/getty 38400 tty3
tty4::respawn:/sbin/getty 38400 tty4
tty5::respawn:/sbin/getty 38400 tty5
tty6::respawn:/sbin/getty 38400 tty6
::ctrlaltdel:/bin/umount -a -r
::shutdown:/bin/umount -a -r
::shutdown:/sbin/swapoff -a

#3 #echo $SHELL (SSH connection)

/bin/bash

#echo $SHELL (monitor keyboard)

/bin/sh

#4 #echo $TERM (SSH connection)

xterm

#echo $TERM (monitor keyboard)

xterm

#5 #tty (SSH connection)

/dev/pts/0

#tty (monitor keyboard)

/dev/console

#6 #ls -l /dev/console /dev/tty[0-9]

crw-rw----    1 root     root        5,   1 Jan  4 04:31 /dev/console
crw-rw----    1 root     root        4,   0 Jan  4 04:31 /dev/tty0
crw-rw----    1 root     root        4,   1 Jan  4 04:32 /dev/tty1
crw-rw----    1 root     root        4,   2 Jan  4 04:31 /dev/tty2
crw-rw----    1 root     root        4,   3 Jan  4 04:31 /dev/tty3
crw-rw----    1 root     root        4,   4 Jan  4 04:31 /dev/tty4
crw-rw----    1 root     root        4,   5 Jan  4 04:31 /dev/tty5
crw-rw----    1 root     root        4,   6 Jan  4 04:31 /dev/tty6
crw-rw----    1 root     root        4,   7 Jan  4 04:31 /dev/tty7
crw-rw----    1 root     root        4,   8 Jan  4 04:31 /dev/tty8
crw-rw----    1 root     root        4,   9 Jan  4 04:31 /dev/tty9

Answer 1

On the "monitor keyboard" stty -a output, there is -isig -icanon -iexten, while the SSH session has these features enabled (no - sign in the front).

And the man stty describes these as follows:

[-]icanon
enable special characters: erase, kill, werase, rprnt

[-]iexten
enable non-POSIX special characters

[-]isig
enable interrupt, quit, and suspend special characters

So, with -isig, the Control-C, Control-\ and Control-Z special functions are switched off. Likewise, -icanon indicates the erase, kill, werase and rprnt functions won't take effect either. You can fix this with stty isig icanon on the monitor keyboard session.

This might be because you are starting /bin/sh directly in /etc/inittab without using something like a getty process to initialize the TTY device settings to well-known values at the beginning of the login process.

If you want to run a shell directly from inittab without a login requirement, you should do any necessary TTY initialization yourself in /etc/init.d/rcS, for example:

for i in 1 2 3 4 5 6; do
    stty -F /dev/tty$i isig icanon
done

On a SSH session, pseudo-TTY devices (PTYs for short) are used, and sshd takes care of their initialization automatically.

/dev/console as the result of the tty command output is a bit suspicious. On the x86 architecture at least, the /dev/console is essentially a compatibility alias for whatever is the currently active console device: it might normally connect to /dev/tty0 (i.e. the currently-active KVM virtual console) but it might point to a serial port like /dev/ttyS0 if a console= kernel boot option was used.

Does your kernel have all the following configuration options enabled?

• CONFIG_VT_CONSOLE=y
• CONFIG_HW_CONSOLE=y
• CONFIG_VT_HW_CONSOLE_BINDING=y
• either CONFIG_VGA_CONSOLE=y or CONFIG_FRAMEBUFFER_CONSOLE=y and an appropriate framebuffer console driver, like CONFIG_FB_VESA=y for classic BIOS or CONFIG_FB_EFI=y for UEFI, and/or maybe also CONFIG_DRM_FBDEV_EMULATION=y if using newer Direct Rendering GPU drivers on the console.

Are the console device nodes set up correctly? On a Debian 12 system, ls -l /dev/console /dev/tty[0-9] has the following output:

crw--w---- 1 root tty 5, 1 Nov 10 02:26 /dev/console
crw--w---- 1 root tty 4, 0 Nov 10 02:25 /dev/tty0
crw--w---- 1 root tty 4, 1 Jan 30 13:37 /dev/tty1
crw--w---- 1 root tty 4, 2 Nov 10 02:25 /dev/tty2
crw--w---- 1 root tty 4, 3 Nov 10 02:25 /dev/tty3
crw--w---- 1 root tty 4, 4 Nov 10 02:25 /dev/tty4
crw--w---- 1 root tty 4, 5 Nov 10 02:25 /dev/tty5
crw--w---- 1 root tty 4, 6 Nov 10 02:25 /dev/tty6
crw--w---- 1 root tty 4, 7 Nov 10 02:26 /dev/tty7
crw--w---- 1 root tty 4, 8 Nov 10 02:25 /dev/tty8
crw--w---- 1 root tty 4, 9 Nov 10 02:25 /dev/tty9

The permissions and ownerships may vary according to current logins & how your distribution chooses to handle them, but the major/minor device numbers (the two digits separated by comma and whitespace) should be exactly like this.