(36) 终端 的概念:
shell 包裹了 linux 内核。shell 利用内核的功能提供了一个可视化界面 ,并接收人们的命令,交给内核执行 。 shell 相当于可执行文件。
相关的概念,还有会话,进程组,进程,首领。
(37) 介绍一个新的 函数 sleep :
++ 开始编写 linux 里的程序,在 vscode 上写源代码,用 xftp 传递到 linux 上编译运行:
++
++ 关闭终端,也会关闭该 bash shell 打开的所有进程 。
++
++ 进程基础: shell 上被启动的进程,都会成为该 shell 的子进程 :
++
关于会话、进程组的概念与赋值, bash 会自动处理。
(38) 父进程的退出,并不意味着子进程要退出。子进程可以交给 1 号进程管理 。本页后面有 do_exit 的代码。可见并不同于 linux0.11 的代码。可能是 linux 版本升级,有些函数的语义更新了。或者说 shell 进程是特殊的父进程。 但 shell 被关闭,会给其所有子进程发送 SIGHUP = 1(hang up 挂断控制终端或进程)信号,子进程收到此信号后就全会结束执行了。 同样 在 shell 上输入 ctrl + c ,会导致 shell 给当前前台进程发送 SIGINT = 2 (interrupt 来自键盘的中断)信号。因为这些信号没有注册信号处理函数。那么按照默认的信号处理策略就是结束本进程,而信号也会成为本进程的退出码交给父进程。
++
++
++
++
(39) 接着介绍 strace 工具。这是 linux 自带的工具。s – signal ,system 系统工具,用来进行跟踪的工具。
首先熟悉一个语法:
++
++
++
++
++ 可见 ,通过 strace 工具,了解了信号是怎么产生和在进程间传递的。
(40) 如何在 bash 退出时,其创建的进程不被退出? 答案是修改信号的处理函数。
++ 先修改源代码:
++ 如何让源代码不报错呢 ?
++ 再次测试:
++
++ 参考的 linux 0.11 的代码:
++ 信号处理函数的注册
++信号处理,此处可见, ignore 会导致信号处理函数的直接返回:
++ 进程的退出函数,可见,会把自己的子进程交给 1 号进程:
+++++ 另一种方法 setsid 函数,修改进程所属的会话 。该函数的 linux0.11 的版本是如此。其定义在 linux 操作系统源代码的 kernel/sys.c 文件。但在 vscode 里查找不到这个源代码定义:
++
++ kill - 9 pid 来强制杀死进程。 9 = SIGKILL
(41) 我们再次修改源代码。上面看的结果是 bash 直接创建的进程,始终属于 bash 会话,接受 bash 会话的控制。 但经 fork() 函数创建的进程,调用了 setsid() 后,就会把自己变成会话首领,脱离原来的会话,且其本身成为了不拥有终端的会话,即后台会话。
++ 测试一下关闭 bash 的结果 。这个结果还是符合 linux0.11 里 setsid 的定义的。至于为啥 bash 的直接子进程不符合 setsid 的定义,不知 。 linux0.12 也没有源码上的改变。进程组,在后面有解释:
++ 也为父进程加上 setsid() 函数的测试结果如下:
++ 王老师讲解了原因 。可见 bash 创建的进程,自动成为了进程组的组长。:
++ 补充一些会话首领进程与拥有终端资源的关系:
(42) 介绍另一个关闭终端 shell 却不关闭其中进程的方法: 以 setsid 命令启动进程:
(43) 再介绍一个关闭 bash 时,不结束其中进程的方法, 以 onhup 命令启动进程 nohup ./a.out :
补充: 原代码输出数据的速度太慢了。其是攒够缓存了才向 nohup.out 写一次文件。加快写入的量以后,观察到了 nohup.out 的大小变化:
(44) 这里的练习,需要多次终止进程,来学习下 kill 命令的正确使用,这里也提到了信号量 SIGTERM 与 SIGKILL 的区别。
(45) 总结一下: bash 给所属会话的进程发送 SIGHUP 信号,来终止所属的进程。为了改变这个默认处理方式,有两个手段,要么改变进程对信号的响应方式,要么把进程脱离原所属会话。每个手段又有代码编写和使用 bash 命令的两个方法。代码方法 : signal() 函数,setsid() ; 命令方法 : nohup ./a.out 或者 setsid ./a.out 。 很显然命令方式是为了避免手动修改代码。
(46) 以命令 nohup ./a.out 运行进程,会导致进程不在往屏幕输入。但这还不算后台进程。因为该进程占据了 bash 界面。
++
++
(47)
谢谢