终端的问题涉及几个概念，那就是进程组，会话，作业，下面会分别进行介绍。会话包含了一系列的进程，这些进程按照不同的执行内容会组织成若干进程组，一个会话内的所有进程都必须是该会话首长进程的后代，这样就保证了这些进程都是由该会话首长进程直接或者间接开启的，只有这样的才能保证这些进程确实是在会话首长进程耳目视线之内的，同时，孤儿进程组不再受到会话首长进程的控制。
作业：
只有一个终端，但是有很多事情要同时做，或者起码分时做，不能先做完一件事再做另一件，怎么办？毕竟启动一个进程后该进程就会独占终端啊，毕竟shell会将它设置为前台进程组进程啊。这就是作业的功能，只需要在一个命令后加一个&符号就可以了，比如我要执行x，那么就敲入：
x &
shell的结果是：
[1] 1234
此处1234是进程的pid，而1则是作业的id，这样这个x就不占用终端了，shell可以启动其它的进程或者作业了，比如又启动了作业2：
[2] 4321
此时想起作业1需要使用一下终端来输入一些信息了，那么就使用：fg %1将作业1置于前台(作业1中目前只有一个进程)，置于前台的作业如何重新放到后台呢？只需要用SIGSTOP信号停止前台使用终端的进程即可，然后该进程就放开终端的占用了
进程组：一个作业就是一个进程组，单独的进程可以独占一个进程组也可以加入同一会话的别的进程组，必须要满足的条件是，同一进程组的所有进程都要是一个会话的后代。所谓的进程组是为了组织作业或者组织同一类任务的。
控制终端：
一个会话的建立者有权力申请一个控制终端，在该控制终端中可以接受标准输入，可以发送shell理解的控制快捷键，可以创建作业并且使用会话头进程提供的作业控制功能。控制终端只能由会话头进程创建，并且控制终端是独占的，只要有一个进程将一个终端当成了控制终端，别的进程不管它是谁都不能这么做了，tty_open中的最后有下面几行代码
if (!noctty &&
    current->signal->leader &&
    !current->signal->tty &&
    tty->session == 0) {
    task_lock(current);
    current->signal->tty = tty;
    task_unlock(current);
    current->signal->tty_old_pgrp = 0;
    tty->session = current->signal->session;  //设置session
    tty->pgrp = process_group(current);
}
可见别的进程是无权申请控制终端的。
     这个控制终端平时给谁用呢？最不容被怀疑的会话首长申请了终端，因为如果连他都值得怀疑的话，后面的属于他的孩子进程们都值得怀疑了，首长申请的终端就是给这些孩子们用的，首长将这些孩子们分成了若干的进程组，指定一个组为前台进程组，只有这个前台进程组的进程才能使用控制终端。bash一般会作为会话首长存在，bash将为一个执行的命令都创建一个进程组，它在接受一个命令准备执行的时候会将该进程设置为前台进程组，它在接受了命令行后加&的命令时，会创建一个作业，并且将它设定为后台进程组，那么此时前台是谁呢，是bash自己哦。后台进程不能使用终端，如果使用&执行了内部带有诸如getchar之类函数的进程，那么其将会收到SIGTTIN信号，不过可以使用fg命令将这类进程提到前台。
控制进程：
很显然，首先控制进程是一个会话的首长进程，另外即使是会话首长也只能通过终端来控制别的进程，所谓的控制就是发送信号而不是操作内存之类的，这也是进程间通信的一种方式。因此所谓的控制进程就是申请到控制终端的进程。
孤儿进程组：
有孤儿进程，对应的也有孤儿进程组的概念。为何引入这个概念以及这个概念的引入需要OS的实现者作些什么呢？先看两个前提，首先，posix用一个session的概念来描述一次用户的登录以及该用户在此次登录后的操作，然后用作业的概念描述不同操作的内容，最后才用进程的概念描述不同操作中某一个具体的工作；其次，unix最初将所有的进程组织成了树的形式，这样就便于追踪每个进程也便于管理(想想看，人类政治社会也是一个类似树形结构：君主专制，两院制等)。有了上述两个前提事情就很明白了，一切都是为了便于管理，一切都是为了登录用户的安全，即此次登录用户的作业是不能被下个登录用户所控制的，即使它们的用户名一致也是不行的，因此所谓的孤儿进程组简单点说就是脱离了创造它的session控制的，离开其session眼线的进程组，unix中怎样控制进程，怎样证明是否在自己的眼线内，那就是树形结构了，只要处于以自己为根的子树的进程就是自己眼线内的进程，这个进程就是受到保护的，有权操作的，而在别的树枝上的进程原则上是触动不得的(又想说说windows的远程线程创建了，可是说的话还要接着说其复杂的令牌机制，否则windows粉丝不服气，所以不说了罢)，unix中建立进程使用fork，自然地这么一“叉子”就形成了自己的一个树枝，当然在自己眼线了，一般对于登录用户而言一个会话起始于一次login之后的shell，只要该用户不logout，在该终端的shell上执行的所有的非守护进程都是该shell的后代进程，因此它们组成一个会话，全部在shell的眼线中，一个会话终止于会话首长的death。现在考虑一下终端上的shell退出后的情景，按照规定，该终端上所有的进程都过继给了别的进程，大多数情况是init进程，然后紧接着另外一个用户登录了这个终端或者知道前一个登录用户密钥的另一个有不好念头的人登录了该终端，当然为其启动的shell创建了一个新的session，由于之前登录的用户已退出，现在登录的用户由于之前用户的进程组都成了孤儿进程组，所以它再有恶意也不能控制它们了，那些孤儿进程组中的成员要么继续安全的运行，要么被shell退出时发出的SIGHUP信号杀死。
     POSIX的规定是铁的纪律，而unix或者linux的不管是内核还是shell的实现则是一种遵守纪律的方式，铁的纪律要求作业控制要以session为基本，就是说不能操作别的session内的进程组，所以类似fg和bg等命令就不能操作孤儿进程，因此如果由于后台进程组由于读写终端被SIGSTOP信号停了，而后它又成了孤儿进程组的成员，那怎么办？别的session的作业控制命令又不能操作它，即使ps -xj找到了它然后手工发送了SIGCONT，那么它还是没法使用终端，这是POSIX的另一个纪律要求的，只有唯一和终端关联的session中的前台进程组的进程可以使用终端，因此只要有一个shell退出了，最好的办法就是将其session内的所有的进程都干掉，因此SIGHUP的原意就是如此，但是完全可以忽略这个信号或者自己定义对该信号的反应。POSIX的基本限制就是session的ID是不能设置的，因为它是受保护的基本单位，但是进程组的ID是可以设置的，毕竟它只是区分了不能的作业，最后进程的PID也是不能设置的，因为它是进程的内秉属性，形成树形进程结构的关键属性。
     POSIX对孤儿进程组的定义：组中没有一个进程的父进程和自己属于同一个会话但是不同进程组的。
守护进程：
守护进程需要做几件事：
1.fork一个子进程：由于bash在执行程序的时候会在fork和exec之间将该程序设置为前台进程组进程，这里的fork之后不进行如此设置，那么子进程就会成为后台进程，并且没有独占一个进程组，子进程属于父进程的进程组。
2.调用setsid开启一个新的会话，开启一个新的进程组，该进程成为一个新的会话的首长。
3.再次fork一个子进程，这样可以避免第一次fork时的子进程重新申请控制终端，毕竟它是会话首长。
4.关闭所有文件描述符，特别关闭0，1，2等和终端相关的描述符，因为已经没有终端了。
5....