第四章linux进程控制

第四章linux进程控制内容摘要：

程结束时内核就写一个会计记录。 典型的会计记录是 3 2字节长的二进制数据，包括命令名、所使用的 C P U时间总量、用户 I D和组 I D、起动时间等。 记帐记录所需的各个数据都由内核保存在进程表中，并在一个新进程被创建时置初值 (例如 fork之后在子进程中 )。 进程终止时写一个会计记录。 这就意味着在记帐文件中记录的顺序对应于进程终止的顺序，而不是它们起动的顺序。 为了确定起动顺序，需要读全部记帐文件，并按起动日历时间进行排序。 这不是一种很完善的方法，因为日历时间的单位是秒，在一个给定的秒中可能起动了多个进程。 记帐记录对应于进程而不是程序。 在 f o r k之后，内核为子进程初始化一个记录，而不是在一个新程序被执行时。 虽然 e x e c并不创建一个新的记帐记录，但相应记录中的命令名改变了， A F O R K标志则被清除。 这意味着，如果一个进程顺序执行了三个程序 (A exec B,B exec C,最后 C exit)，但只写一个会计记录。 在该记录中的命令名对应于程序 C，但 C P U时间是程序 A、 B、 C之和。 include int acct(const char *filename)。 进程执行时间 用户进程可以通过调用 t i m e s函数获得它自己及终止子进程的时间值。 此函数填写由 buf指向的 tms结构，该结构定义如下： struct tms { clock_t tms_utime。 /* user time */ clock_t tms_stime。 /* system time */ clock_t tms_cutime。 /* user time of children */ clock_t tms_cstime。 /* system time of children*/ }。 结构中两个针对子进程的字段包含了此进程已等待到的各子进程的值 由此函数返回的 clock_t值都用 _SC_CLK_TCK (由 sysconf函数返回的每秒时钟滴答数）变换成秒数。 include sys/ clock_t times(struct tms *buf)。 小结 对在 LINUX环境中的高级程序设计而言，完整地了解 LINUX的进程控制非常重要。 其中必须熟练掌握的只有几个 —— fork、 exec族、 _exit、wait和 waitpid。 通过对这些接口的理解，我们应该了解LINUX下新 进程是怎么产生的。 不同的程序又是如何执行的。 以及进程控制的一些基本内容。 对各种不同的用户 I D和组 I D (实际，有效和保存的 )的理解和编写安全的设置 用户 I D程序是至关重要的。 本章的最后，我们还介绍了 LINUX下的几个辅助系统调用。 第六章 LINUX下的信号 信号的本质 信号是在软件层次上是对中断机制的一种模拟，在原理上，一个进程收到一个信号与处理器收到一个中断请求可以说是一样的。 信号是异步的，一个进程不必通过任何操作来等待信号的到达，事实上，进程也不知道信号到底什么时候到达。 信号是进程间通信机制中唯一的异步通信机制，可以看作是异步通知，通知接收信号的进程有哪些事情发生了。 信号机制经过 POSIX实时扩展后，功能更加强大，除了基本通知功能外，还可以传递附加信息。 信号的来源 信号事件的发生有两个来源： 硬件来源 硬件中断触发，如键盘 其它硬件故障，如 IO BUS error 硬件触发的程序异常 软件来源 程序或命令控制的信号，如： kill, raise等 系统闹钟 程序调试 程序异常，如：段违例、非法运算等操作 … 信号的种类 可以从两个不同的分类角度对信号进行分类： 1) 可靠性方面：可靠信号与不可靠信号； 2) 与时间的关系上：实时信号与非实时信号。 不可靠信号 Linux信号机制基本上是从 Unix系统中继承过来的。 早期Unix系统中的信号机制比较简单和原始，后来在实践中暴露出一些问题，因此，把那些建立在早期机制上的信号叫做“ 不可靠信号 ” ，信号值小于 SIGRTMIN(Red hat LINUX中，SIGRTMIN=32， SIGRTMAX=63)的信号都是不可靠信号。 这就是 “ 不可靠信号 ” 的来源。 它的主要问题是： 进程每次处理信号后，就将对信号的响应设置为默认动作。 在某些情况下，将导致对信号的错误处理；因此，用户如果不希望这样的操作，那么就要在信号处理函数结尾再一次调用 signal()，重新安装该信号。 信号可能丢失。 早期 unix下的不可靠信号主要指的是进程可能对信号做出错误的反应以及信号可能丢失。 这种情况主要出现在：当信号处理函数执行过程中到来的所有相同信号，都被合并为一个信号。 不可靠信号示例 说明： 这段代码段的一个问题是：在信号发生之后到信号处理程序中调用signal函数之间有一个时间窗口。 在此段时间中 ， 可能发生另一次中断信号。 第二个信号会造成执行默认动作 ， 而对中断信号则是终止该进程。 这种类型的程序段在大多数情况下会正常工作 ， 使得我们认为它们正确 ，而实际上却并不是如此。 Linux支持不可靠信号，但是对不可靠信号机制做了改进：在调用完信号处理函数后，不必重新调用该信号的安装函数（信号安装函数是在可靠机制上的实现）。 因此， Linux下的不可靠信号问题主要指的是信号可能丢失。 可靠信号 随着时间的发展，实践证明了有必要对信号的原始机制加以改进和扩充。 所以，后来出现的各种 Unix版本分别在这方面进行了研究，力图实现 “ 可靠信号 ”。 由于原来定义的信号已有许多应用，不好再做改动，最终只好又新增加了一些信号，并在一开始就把它们定义为可靠信号，这些信号支持排队，不会丢失。 信号的发送和安装也出现了新版本：信号发送函数 sigqueue()及信号安装函数 sigaction()。 POSIX对可靠信号机制做了标准化。 但是， POSIX只对可靠信号机制应具有的功能以及信号机制的对外接口做了标准化，对信号机制的实现没有作具体的规定。 信号值位于 SIGRTMIN和 SIGRTMAX之间的信号都是可靠信号，可靠信号克服了信号可能丢失的问题。 Linux在支持新版本的信号安装函数 sigation()以及信号发送函数 sigqueue()的同时，仍然支持早期的 signal()信号安装函数和 kill()函数。 一点说明 可靠信号是指后来添加的新信号（信号值位于 SIGRTMIN及 SIGRTMAX之间）；不可靠信号是信号值小于SIGRTMIN的信号。 信号的可靠与不可靠只与信号值有关，与信号的发送及安装函数无关。 目前 linux中的 signal()是通过 sigation()函数实现的，因此，即使通过 signal（）安装的信号，在信号处理函数的结尾也不必再调用一次信号安装函数。 同时，由 signal()安装的实时信号支持排队，同样不会丢失。 对于目前 linux的两个信号安装函数 :signal()及 sigaction()来说，它们都不能把 SIGRTMIN以前的信号变成可靠信号（都不支持排队，仍有可能丢失，仍然是不可靠信号），而且对SIGRTMIN以后的信号都支持排队。 这两个函数的最大区别在于， 经过 sigaction安装的信号都能传递信息 给信号处理函数（对所有信号这一点都成立），而经过 signal安装的信号却不能向信号处理函数传递信息 ,对于信号发送函数来说也是一样的。 实时信号和非实时信号 LINUX中信号的编号为 063，将来可能进一步增加，这需要得到内核的支持。 前 32种信号已经有了预定义值，每个信号有了确定的用途及含义，并且每种信号都有各自的缺省动作。 后 32个信号 (SIGRTMIN=31， SIGRTMAX=63)表示实时信号，等同于前面阐述的可靠信号。 这保证了发送的多个实时信号都被接收。 实时信号是 POSIX标准的一部分，可用于应用进程。 非实时信号都不支持排队，都是不可靠信号；实时信号都支持排队，都是可靠信号。 进程对信号的响应 进程可以通过三种方式来响应一个信号： 1) 忽略信号 (SIG_DFL)，即对信号不做任何处理，其中，有两个信号不能忽略： SIGKILL及 SIGSTOP； 2) 捕捉信号 (CATCH)。 定义信号处理函数，当信号发生时，执行相应的处理函数； 3) 执行缺省操作 (SIG_IGN)， Linux对每种信号都规定了默认操作，详细情况请参考下表。 注意，进程对实时信号的缺省反应是进程终止。 Linux究竟采用上述三种方式的哪一个来响应信号，取决于传递给相应 API函数的参数。 关于上表的说明 在系统默认动作列 ， “ 终止 w / c o r e”表示在进程当前工作目录的产生了 c o r e文件 ， 该文件中记录了该进程非正常退出时的存储图像 ， 大多数 U N I X调试程序都使用 c o r e文件以检查进程在终止时的状态。 在下列条件下不产生 c o r e文件： ( a )进程是设置 用户 ID， 而且当前用户并非程序文件的所有者 ( b )进程是设置 组 ID， 而且当前用户并非该程序文件的组所有者 ( c )用户没有写当前工作目录的许可权 ( d )文件太大。 core文件的许可权 (假定该文件在此之前并不存在 )通常是用户读／写，组读和其他读。 LINUX信号列表 (按序号排列 ) SIGHUP：如果终端界面检测到一个连接断开，则将此信号送给与该终端相关的控制进程（对话期首进程）。 SIGINT：当用户按中断键（一般采用 DELETE或 CtrlC）时，终端驱动程序产生此信号并送至前台进程组中的每一个进程。 当一个进程在运行时失控，特别是它正在屏幕上产 生大量不需要的输出时，常用此信号终止它。 SIGQUIT：当用户在终端上按退出键（一般采用 Ctrl\）时，产生此信号，并送至前台进程组中的所有进程。 此信号不仅终止前台进程组（如 SIGINT所做的那样），同时产生一个 core文件 SIGILL：此信号指示进程已执行一条非法硬件指令 SIGTRAP：指示一个实现定义的硬件故障，一般用于跟踪调试自陷 SIGABRT：调用 abort函数时产生此信号。 进程异常终止 SIGIOT： IOT自陷，指示一个实现定义的硬件故障 SIGBUS：总线错，指示一个实现定义的硬件故障 SIGFPE：浮点相关异常 SIGKILL：这是两个不能被捕捉或忽略信号中的一个。 它向系统管理员提供了一种可以杀死任一进程的可靠方法。 SIGUSR1：用户自定义信号 LINUX信号列表 (续 ) SIGSEGV：存储访问相关的异常，一般为非法存储空间读写引起 SIGUSR2：用户自定义信号 SIGPIPE：如果在读进程已终止时写管道，则产生此信号。 当套接口的一端已经终止时，若进程写该套接口也产生此信号 SIGALRM： 用 alarm函数设置的时间到达时产生此信号。 若由 s e t i t i m e r ( 2 )函数设置的间隔时间已经过时，那么也产生此信号 SIGTERM：终端信号， 是由 kill(1)命令 发送的系统默认终止信号 SIGSTKFLT：栈故障相关信号 SIGCHLD：在一个进程终止或停止 时， SIGCHLD信号被送给其父进程。 按系统默认，将忽略此信号。 如果父进程希望了解其子进程的这种状态改变，则应捕捉此信号。 信号捕捉函数中通常要调用 wait函数以取得子进程 ID和其终止状态。 SIGCONT：跟踪调试时的继续信号 SIGSTOP： 是一个作业控制信号，它停止一个进程， SIGSTOP不能被捕捉或忽略  SIGTSTP：交互停止信号，当用户在终端上按挂起键（一般采用 CtrlZ）时，终端驱动程序产生此信号。 LINUX信号列表 (续 ) SIGTTIN：当一个后台进程组进程试图读其控制终端时，终端驱动程序产生此信号。 在下列例外情形下不产生此信号，此时读操作返回出错， errno设置为 EIO： (a)读进程忽略或阻塞此信号，或 (b)读进程所属的进程组是孤儿进程组。 SIGTTOU：当一个后台进程组进程试图写其控制终端时产生此信号。 与上面所述的 SIGTTIN信号不同，一个进程可以选择为允许后台进程写控制终端。 如果不允许后台进程写，则与 SIGTTIN相似也有两种特殊情况： ( a )写进程忽略或阻塞此信 不幸的是，术语停止 ( s t o p )有不同的意义。 在讨论作业控制和信号时我们需提及停止和继续作业。 但是终端驱动程序一直用术语停止表示用 C t r l S和 C t r l Q字符停止和起动终端输出。 因此，终端驱动程序将产生交互停止信号和字符称之为挂起字符而非停止字符。 号，或 ( b。