linux 终端下敲ctrl-c时，到底发生了什么?(转)

通过telnet登录到单板，然后按ctrl-c会发生什么情况，流程是怎么样的？

在分析之前，先介绍tty的相关知识。
我们可以认为，所有跟输入输出相关的操作，最终都由tty来接管。
举例来说，当我们敲 ls /dev时得到

另外还可以通过 /proc/tty/drivers得到tty相关驱动信息

tty  控制终端，control terminal 这个是跟进程相关的，可以理解为一个指针，指向具体的tty终端设备。

     进程可以通过open /dev/tty来获取当前进程使用的tty终端具体是哪个，例如是ptmx，还是pts/2，还是

tty2，或者是ttyS0
     linux shell下tty命令的可以查看当前进程的控制终端。例如：
     [root@ dev]# tty
     /dev/pts/10
     具体的实现是靠ttyname(0)
     即返回当前进程的标准输入，对应的tty终端设备是哪个。

     另外通过ps -ax可以查看系统所有进程的控制终端，如：

ptmx 伪终端主
pts  伪终端从
tty0-tty63  虚拟终端，也叫虚拟控制台终端，virtual console ternimal 通常情况下是6个，这里我们查看
的服务器有63个
tty0可以理解为指针
ttyS0-ttyS3 串口终端 

刚才说到，/proc/pid/stat的第7个字段是进程控制终端的设备号，可以根据此设备号得到具体的设备名。

例如：

即1025，十六进为0x401 ，主设备号为高4字节4，次设备号为低字节1，

对照/proc/tty/drivers得到

即tty1。再根据ps -ax | grep 781得到

确实是吻合的。

扯远了，下面来看telnet的流程

26912 ?        Ss     0:00 busybox telnetd
当用户通过telnet客户端连接telnetd后
26912 ?        Ss     0:00 busybox telnetd
27030 ?        Ss     0:00 login -- chenyu
27038 pts/6    Ss+    0:00 -bash

可以看出telnetd先fork出gettty并执行login，登录成功后则再fork出实际的bash，

这个bash用的是伪终端pts/6，

以下数据的PPid字段可以证明：
Name:   busybox
PPid:   1

Name:   login
Pid:    27030
PPid:   26912

Name:   bash
Pid:    27038
PPid:   27030

bash并不知道这个pts/6具体是个什么设备，只知道往里面读写。
每次在telnet客户端，敲一个字符，就会把数据发给telnetd，telnetd再操作ptmx通过
tty displine将数据格式化传递给pts/6，然后bash从pts/6收到数据进行处理，再写回pts/6，
传给ptmx，由telnetd将数据再传递回telnet客户端。 可以通过每次在telnet客户端
敲一个字符，telnetd的调度次数就增加2，来大体验证这个流程（telnetd收到客户端数据被唤醒，bash通过
伪终端把数据写回唤醒telnetd，一共两次唤醒）

具体的telnet流程图如下：





说完了telnetd的原理，再来看看在telnet客户端敲ctrl-c时，系统会发生什么。
首先可以明确的是，ctrl-c传递到telnetd后，会通过写伪终端主设备ptmx的方式传递给从设备进而传给bash。
那么，到底是telnetd，还是bash端会处理这个ctrl-c？

实际上我们可以这么理解，在直接登录shell时，没有telnetd这一层，

应该是shell进程本身被ctrl-c键盘中断打断，

然后再驱动里通过tty收到了此特殊字符，然后在接收流程里，决定是否给当前进程shell发SIG信号。
那么我们就认为telnetd不过是一个中转站，具体的数据处理还是要靠bash来完成。

因此当bash从pts/6收到ctrl-c特殊字符后，会进行特殊处理。来看这段代码：
首先，不管是伪终端，还是串口，亦或是控制台，接收到字符后都要推送给tty displine 的接收函数
n_tty_receive_buf做进一步处理。n_tty_receive_buf的数据来源是tty->buf。
这个tty->buf的来源，要么是伪终端主设备pty_write写入的数据，要么是中断往里面写入的数据。

如果是伪终端pty_write
static int pty_write(struct tty_struct *tty, const unsigned char *buf, int c)
{
     //得到从设备
struct tty_struct *to = tty->link;


if (tty->stopped)
return 0;


if (c > 0) {
/* Stuff the data into the input queue of the other end */
     //让从设备强行收数据，即将buf数据传递给从设备的tty->buf
c = tty_insert_flip_string(to, buf, c);
/* And shovel */
if (c) {
            //将从设备的tty->buf临时缓冲数据提交给displine处理，即提交给tty->read_buf
            //供用户空间使用
             //这个一般是通过schedule_work来完成
tty_flip_buffer_push(to);
tty_wakeup(tty);
}
}
return c;
}

如果是串口中断，则是
serial8250_interrupt->serial8250_handle_port->receive_chars->
uart_insert_char->tty_insert_flip_char 将串口数据拷贝到tty->buf中之后，
再tty_flip_buffer_push(tty);将数据推送给displine处理

因此可以看出，串口和伪终端的不同之处在于，数据来源不同，一个是tty_write写入的，
一个是串口中断接受到的。
所以，我们在串口，或者是在telnet下，敲ctrl-c，实际上都会走到tty_flip_buffer_push，
进行数据的分析和接受。具体的特殊字符解析，应该也是在tty_flip_buffer_push之后的步骤完成。

那下面我们来看tty_flip_buffer_push
* This routine is called out of the software interrupt to flush data
* from the buffer chain to the line discipline.


最终调到到receive_buf->n_tty_receive_buf->n_tty_receive_break->
isig(SIGINT, tty, 1);->
if (tty->pgrp)
kill_pgrp(tty->pgrp, sig, 1);

即向进程组发送INT信号。

有了上面的知识铺垫，我们来看一个实际的问题。

我们先说明，这是一个busybox 1.13版本的bug，后来已经在高版本修复。

故障现象是这样的：

mips32&64  busybox 1.13 kernel 2.6.32

在串口终端执行如下脚本：

./tftp -r file_256M -g 192.168.1.1

 ‘echo 1‘

然后在tftp下载过程中，按ctrl-c

那么tftp进程将变成Z

故障的场景：
1）# ./test.sh之后 ash fork生成一个sh， 这个sh尝试按行解析test.sh，每读取一行就fork一个新进程并exec去执行。 然后sh通过waitpid等待子进程的完成。  正常情况下，两条命令顺序执行完，一切都结束的很好。

2）如果sh在waitpid过程中，即等待tftp完成的过程中，正好收到了SIGINT信号，那么sh就被人从阻塞状态里唤醒。

do_wait继续进入轮询检查到tftp不是为Z（因为这个时候tftp还没得到调度），所以不会回收tftp，然后退出系统调用返回用户态

时检查到有pending的SIGINT，于是get_signal_to_deliever，

由于sh注册了SIGINT信号的处理函数onsig，因此不会do_group_exit
3）onsig执行完之后，再解析下一条命令`echo 1` , 由于sh发现这条命令是引号包起来的，   说明是一个子命令，因此sh再次fork一个进程sh_2，去执行echo 1,并且通过管道pipe_wait等待   sh_2的echo 1的结果
4）sh_2在解析echo 1的过程中，需要获取tty串口的信息，由于这个时候控制终端tty串口已经被sh占有，所以sh_2    就会一直阻塞在tty_read，造成与sh的互锁。
因此问题出在，第3步sh如果收到了SIGINT信号，就不应该继续执行下一条echo 1指令了，而是整个进程退出 后面的一系列问题都是错误的流程导致的错误的结果。

附出问题时的阻塞现场

941 root      3840 S    -/bin/ash 
  955 root      3840 S    /bin/sh 
  969 root      3792 S    /bin/sh ./test.sh    //即上文的sh
  970 root         0 Z    [tftp]
  971 root      3792 S    /bin/sh ./test.sh    //sh收到ctrl-c后不做处理，继续fork,尝试解析echo 1字符
  972 root      3856 R    ps 

(gdb) attach 969
The target endianness is set automatically (currently big endian)
[New Thread 969]
0x0000000120013370 in read ()
(gdb) bt
#0  0x0000000120013370 in read ()
#1  0x00000001200fe9d4 in safe_read (fd=3, buf=0xffffa53bf8, count=128)
    at libbb/read.c:27
#2  0x00000001200fea68 in nonblock_safe_read (fd=3, buf=0xffffa53bf8, 
    count=128) at libbb/read.c:75
#3  0x000000012018fd3c in expbackq (cmd=0x120341b48, quoted=0, quotes=0)
    at shell/ash.c:5557
#4  0x0000000120190580 in argstr (p=0x120341b6b "", flag=68, var_str_list=0x0)
    at shell/ash.c:5783
#5  0x0000000120193574 in expandarg (arg=0x120341b70, arglist=0xffffa53e40, 
    flag=4) at shell/ash.c:6829
#6  0x0000000120198304 in evalcommand (cmd=0x120341b90, flags=0)
    at shell/ash.c:8813
#7  0x0000000120196474 in evaltree (n=0x120341b90, flags=0)
    at shell/ash.c:8005
#8  0x000000012019fd6c in cmdloop (top=1) at shell/ash.c:11739
#9  0x00000001201a46e8 in ash_main (argc=2, argv=0xffffa54408)
    at shell/ash.c:13743
#10 0x00000001200fa098 in run_applet_no_and_exit (applet_no=219, 
    argv=0xffffa54408) at libbb/appletlib.c:747
#11 0x00000001200fa10c in run_applet_and_exit (name=0xffffa57f61 "sh", 
    argv=0xffffa54408) at libbb/appletlib.c:754
#12 0x00000001200fa24c in main (argc=2, argv=0xffffa54408)
    at libbb/appletlib.c:791
(gdb) detach 
Ending debugging.
(gdb) attach 971
[New Thread 971]
0x0000000120013370 in read ()
(gdb) bt
#0  0x0000000120013370 in read ()
#1  0x00000001200fe9d4 in safe_read (fd=0, buf=0x12031cd08, count=8191)
    at libbb/read.c:27
#2  0x00000001200fea68 in nonblock_safe_read (fd=0, buf=0x12031cd08, 
    count=8191) at libbb/read.c:75
#3  0x0000000120199148 in preadfd () at shell/ash.c:9139
#4  0x00000001201994d8 in preadbuffer () at shell/ash.c:9258
#5  0x000000012019972c in pgetc () at shell/ash.c:9314
#6  0x000000012019f078 in xxreadtoken () at shell/ash.c:11365
#7  0x000000012019f3a8 in readtoken () at shell/ash.c:11499
#8  0x000000012019f64c in parsecmd (interact=0) at shell/ash.c:11576
#9  0x000000012019fc80 in cmdloop (top=1) at shell/ash.c:11724
#10 0x00000001201a46e8 in ash_main (argc=2, argv=0xffffa54408)
    at shell/ash.c:13743
#11 0x00000001200fa098 in run_applet_no_and_exit (applet_no=219, 
    argv=0xffffa54408) at libbb/appletlib.c:747
#12 0x00000001200fa10c in run_applet_and_exit (name=0xffffa57f61 "sh", 
    argv=0xffffa54408) at libbb/appletlib.c:754
#13 0x00000001200fa24c in main (argc=2, argv=0xffffa54408)
    at libbb/appletlib.c:791
(gdb) 

http://blog.csdn.net/chenyu105/article/details/7738388

linux 终端下敲ctrl-c时，到底发生了什么?(转)

原文：http://www.cnblogs.com/softidea/p/4986369.html