进程控制

子进程是父进程的复制品：

• 如果正文段是 只读的 ，则父、子进程 共享正文段
• 获得父进程的 复制品 ：
  • 数据段
  • 非初始化数据段(bss)
  • 堆
  • 栈

       注意：数据段，bss， 堆，栈是子进程所拥有的独立拷贝

       父、子进程并不共享这些存储空间部分！！！

       现在很多的实现并不做一个父进程数据段和堆的完全拷贝，因为在 fork 之后经常跟随着 exec 执行另外一个程序
       而作为替代使用了在写时复制(Copy-On-Write)的技术

例如：

• fork函数刚刚创建子进程的时候，父、子进程的数据 指向同一块物理内存 ，但是内核将这些 内存的访问变为只读 的了
• 当父、子进程中的任何一个想要 修改数据 的时候
  1. 内核会为 修改区域的那块内存 制作一个 副本
  2. 并将自己的 虚拟地址 映射到 物理地址 的指向修改为 副本的地址

• 从此父子进程互不干扰，效率也提高了许多。新分配的副本大小通常是 虚拟存储系统中的一个页

  ]]

fork一个进程，修改相关变量并打印

#include <sys/types.h>
#include "apue.h"

int glob = 6;
char buf[] = "a write to stdin\n";

int main(void)
{
    int var;
    pid_t pid;

    var = 88;
    if(write(STDOUT_FILENO, buf, sizeof(buf) - 1) != (sizeof(buf) - 1))
        err_sys("write error");
    printf("before fork\n"); // we don't flush stdout

    if( (pid = fork() ) < 0)
        err_sys("fork error");

    else if(0 == pid) { //child process
        // modify variable
        glob++; 
        var++; 
    } else { // parent process
        sleep(2);
    }

    //child & parent share code
    printf("pid = %d, glob = %d, var = %d\n", getpid(), glob, var);
    exit(0);
}

一般来说，在fork之后是 父进程先执行还是子进程先执行是不确定的 ，这取决于内核所使用的 调度 算法

       如果要求父、子进程之间相互同步，则要求某种形式的进程间通信

       在这个程序中父进程使自己睡眠2秒钟，以此使子进程先执行，但2秒钟并不一定保证已经足够

$ ./src/process/forkExample

a write to stdin
#终端是行缓存的，所以printf("before fork")直接输出
before fork
pid = 8898, glob = 7, var = 89 # 子进程打印改变后的变量值
pid = 8897, glob = 6, var = 88 # 父进程打印未改变的变量值

$ ./src/process/forkExample > temp.out

$ cat temp.out 
a write to stdin
#文件是全缓存的，所以fork之前的printf把"before fork\n"放入了缓存，但并没有输出
#fork把父进程的标准IO缓存复制了，因此在最后的prinf("pid= %d ...)也输出了before fork\n
before fork 
pid = 8962, glob = 7, var = 89 #子进程
before fork
pid = 8961, glob = 6, var = 88 #父进程

fork与I/O函数之间的关系：

• 文件IO 是 不带缓存 的：所以"a write to stdin"只被write函数写到标准输出一次
• 标准I/O 库是 带缓存 的：如果标准输出连到终端设备，则它是 行缓存 的，否则它是 全缓存 的
  • 当以 交互方式 运行该程序时：因为标准输出缓存由新行符刷新，所以"before fork"只被printf输出一次
  • 当将 标准输出 重新定向 到 一个文件 时：
    1. 在fork之前调用了printf("before fork")一次，但 当调用fork时该行数据仍在缓存内
    2. 在 父进程数据空间 复制 到 子进程 中时该 缓存数据也被复制到子进程 中，于是那时父、子进程各自有了"before fork"的缓存
    3. 所以当每个进程终止时，其 缓存中的所有内容被写到相应文件中

       因此在 fork进程前 请务必考虑 flush 所有的缓存！！！

       所有由父进程打开的描述符都被复制到子进程中，父、子进程每个相同的打开描述符共享一个文件表项

       所以在上面程序中重定向了父进程的标准输出时，子进程的标准输出也被同样重定向

再比如一个进程打开了三个不同文件，它们是 标准输入 、 标准输出 和 标准出错 。在从fork返回时，有了如图8-1中所示的安排

这种共享文件的方式使 父、子进程对同一文件使用了一个文件位移量

       如果父、子进程写到同一描述符文件，但又没有任何形式的同步(例如使父进程等待子进程)，那么它们的输出就会相互混合，但是这种情况并不常见

在fork之后处理文件描述符有两种常见的情况：

1. 父进程等待子进程完成 。父进程无需对其描述符做任何处理。当子进程终止后，它曾进行过读、写操作的任一共享描述符的文件位移量已做了相应更新
2. 父、子进程各自执行不同的程序段。在fork之后 父、子进程 各自关闭 它们 不需使用 的文件描述符 ，并且不干扰对方使用的文件描述符。这种方法是网络服务进程中经常使用

除了打开文件之外，很多父进程的其他性质也由子进程继承:

• 实际用户ID、实际组ID、有效用户ID、有效组ID
• 添加组ID
• 进程组ID
• 对话期ID
• 控制终端
• 设置-用户-ID标志和设置-组-ID标志
• 当前工作目录
• 根目录
• 文件方式创建屏蔽字
• 信号屏蔽和排列
• 对任一打开 文件描述符的在执行时关闭标志
• 环境
• 链接的共享存储段
• 资源限制

• fork的返回值
• 进程ID
• 不同的父进程ID
• 子进程的tms_utime，tms_stime，tms_cutime以及tms_ustime设置为0
• 父进程设置的锁 ，子进程不继承
• 子进程的未决告警 被清除
• 子进程的未决信号集 设置为空集

• 一个父进程希望复制自己，使 父、子进程同时执行不同的代码段

  	 这在网络服务进程中是常见的：
  
  	 父进程等待委托者的服务请求，当这种请求到达时，父进程调用fork
  	 使子进程处理此请求，父进程则继续等待下一个服务请求
  

• 一个进程要 执行一个不同的程序 。这对 shell 是常见的情况。在这种情况下，子进程在从 fork 返回后立即调用 exec

某些操作系统将第二种用法中的两个操作(fork之后执行exec)组合成一个，并称其为spawn

UNIX将这两个操作分开，因为在很多场合需要单独使用fork，其后并不跟随exec

改写fork实例

#include "apue.h"

// external variable in initialized data
int glob = 6;

int main(void)
{
    // automatic variable on the stack
    int var;
    pid_t pid;

    var = 88;
    printf("before fork\n");

    if((pid = vfork()) < 0) {
        err_sys("fork error");
    } else if(pid == 0) { //child 
        glob++; // change variable 
        var++; 
        _exit(0); //child terminated
        //exit(0) 
    }

    //parent
    printf("pid = %d, glob = %d, var = %d\n", getpid(), glob, var);
    exit(0);
}

子进程对变量glob和var做加1操作，结果 改变了父进程中的变量值 。因为子进程在父进程的地址空间中运行

$ gcc -I/home/klose/Documents/programming/c/apue/include -c -o vforkExample.o src/process/vforkExample.c #编译c文件，注意不能有优化参数！
$ gcc -o vforkExample vforkExample.o src/lib/libapue.a # 链接静态库文件，产生可执行文件

$ ./vforkExample 
before fork
pid = 19302, glob = 7, var = 89

$ gcc -O2 -I/home/klose/Documents/programming/c/apue/include -c -o vforkExample1.o src/process/vforkExample.c 
$ gcc -O2 -o vforkExample1 vforkExample1.o src/lib/libapue.a

$ ./vforkExample1 #由于优化，var被放在寄存器内，所以丢失了子线程的修改
before fork
pid = 19471, glob = 7, var = 88

       子进程对变量的改动只对保存在内存中的变量有效，而对寄存器中的变量有可能会回滚

       如果编译使用了优化参数，结果可能并不同，为了保证效果可以使用 volatile

因为写时复制技术的普及，实际上 vfork 已经是个 过时的 函数， 尽量避免使用vfork

pr_exit使用表8-1中的宏以打印进程的终止状态

       注意：如果定义了WCOREDUMP，则此函数也处理该宏

#include <sys/types.h>
#include <wait.h>
#include "apue.h"

void pr_exit(int status) 
{
    if( WIFEXITED(status) )
        printf("normal termination, exit status = %d\n",
               WEXITSTATUS(status));

    else if( WIFSIGNALED(status) )
        printf("abnormal termination, signal number = %d%s\n",
               WTERMSIG(status),
#ifdef WCOREDUMP
               WCOREDUMP(status) ? "(corefile generated)" : "");

#else
    "");
#endif

else if( WIFSTOPPED(status) ) 
    printf("child stopped, signal number = %d\n",
           WSTOPSIG(status));
}

打印不同终止的状态值

#include <sys/types.h>
#include <wait.h>
#include "apue.h"

int main(void) 
{
    pid_t pid;
    int status;

    if( (pid = fork() ) < 0)
        err_sys("fork error");
    else if(0 == pid)
        exit(7); //子进程正常退出

    if ( wait(&status) != pid)
        err_sys("wait error");
    pr_exit(status);

    if( (pid = fork() ) < 0)
        err_sys("fork error");
    else if(0 == pid)
        abort(); //子进程调用abort

    if ( wait(&status) != pid)
        err_sys("wait error");
    pr_exit(status);

    if( (pid = fork() ) < 0)
        err_sys("fork error");
    else if(0 == pid)
        status /= 0; //子进程产生异常信号

    if ( wait(&status) != pid)
        err_sys("wait error");
    pr_exit(status);

    exit(0);
}

测试：

$ ./src/process/waitExample

normal termination, exit status = 7
abnormal termination, signal number = 6 # SIGABRT
abnormal termination, signal number = 8 # SIGFPE

       不幸的是：没有一种可移植的方法将 WTERMSIG 得到的信号编号映射为说明性的名字

       必须查看<signal.h>头文件才能知道 SIGABRT 的值是 6， SIGFPE 的值是 8

       如果一个进程要fork一个子进程，但不要求它等待子进程终止，也不希望子进程处于僵死状态直到父进程终止

这可以通过 调用fork两次 来实现：

• 第一个fork子线程 提前终止 ，使得由它 fork的第二个子进程 被 init 托管
• 第二个子进程 结束会 自动被 init 进程调用 wait 处理

• 主进程 只需要 等待 第一个子进程终止 即可

  #include <sys/types.h>
  #include <sys/wait.h>
  #include "apue.h"
  
  int main(void)
  {
      //进程p
      pid_t pid;
  
      if( ( pid = fork() ) < 0)
          err_sys("1. fork error");
      else if (0 == pid) { //子进程1，它的父进程是进程p
          if( ( pid = fork() ) < 0)
              err_sys("2.fork error");
          else if(pid > 0) //子进程1 
              exit(0); //结束子进程1
  
          /*
            这是子进程2，它的父进程原本是子进程1，但是因为子进程正常终止了，所以由init进程托管
          */
          sleep(2);
          printf("second child parent pid = %d\n", getppid());
          exit(0); //当子进程2终止时，init进程会调用wait清理子进程2
      }
  
      //进程p阻塞等待子进程1终止，并清理子进程1
      if(waitpid(pid, NULL, 0) != pid)
          err_sys("waitpid error"); 
  
      //进程p终止
      exit(0);
  }
  

  测试：

  $ ./src/process/zombieAvoid
  
  $ second child parent pid = 1 #第一个fork的子进程终止了，它的子进程被init进程托管
  

       在第二个子进程中调用 sleep 是为了保证在打印父进程ID时第一个子进程已终止

       在fork之后，父、子进程都可继续执行，但无法预知哪一个会先执行

       如果不使第二个子进程睡眠，则在fork之后它可能比其父进程先执行，于是它打印的父进程ID将是创建它的父进程，而不是init进程

执行 exec后进程 还 保持 了原进程的下列特征:

• 进程ID 和 父进程ID
• 实际用户ID 和 实际组ID
• 添加组ID
• 进程组ID
• 对话期ID
• 控制终端
• 闹钟尚余留 的时间
• 当前工作目录
• 根目录
• 文件方式创建屏蔽字
• 文件锁
• 进程信号屏蔽
• 未决信号
• 资源限制
• tms_utime，tms_stime，tms_cutime以及tms_ustime值

     与fork进程相比较，子进程是不继承文件锁，未决信号集！！！

对打开文件的处理与每个描述符的 exec关闭标志值 FD_CLOEXEC 有关。进程中每个 打开描述符 都有一个 exec关闭标志 ：

• 若 此标志设置 ，则在执行 exec时关闭该描述符 ，否则该描述符仍打开
• 除非 特地用fcntl设置了该标志 ，否则系统的 默认 操作是在 exec后仍保持这种描述符打开

POSIX.1明确要求在exec时关闭打开目录流

这通常是由 opendir 函数实现的，它调用fcntl函数为对应于打开目录流的描述符设置exec关闭标志

exec的进程 有效ID 是否改变则取决于 所执行程序的文件 的 设置-用户-ID位 和 设置-组-ID位 是否设置：

• 如果新程序的 设置-用户-ID位 已设置 ，则 有效用户ID 变成 程序文件所有者的ID
• 否则： 有效用户ID 不变
• 对 组ID 的处理方式与此相同

       在exec前后 实际用户ID 和 实际组ID 保持不变

程序 echoall 是一个普通程序， 回送 其所有 命令行参数 及其全部 环境表

#include <stdio.h>

int main(int argc, char *argv[])
{
    int i;
    char **ptr;
    extern char **environ;

    for(i = 0; i < argc; i++)
        printf("argv[%d]: %s\n", i, argv[i]);

    for(ptr = environ; *ptr != 0 ; ptr++ )
        printf("%s\n", *ptr);

    exit(0);  
}

调用execle要求一个 路径名 和一个 特定的环境 。下一个调用的是execlp用一个文件名，并将调用者的环境传送给新程序

#include <sys/types.h>
#include <sys/wait.h>
#include "apue.h"

char *env_init[] = { "USER=unknown", "PATH=/tmp", NULL};

int main(void) 
{
    pid_t pid;
    if( (pid = fork() ) < 0 )
        err_sys("fork error");
    else if( 0 == pid ) {
        if(execle("/home/klose/bin/echoall",
              "echoall", "myarg1", "MY ARG2", (char *) 0,
              env_init) < 0 )
            err_sys("execle error");

    }

    if (waitpid(pid, NULL, 0) < 0)
        err_sys("wait error");

    if( (pid = fork() ) < 0 )
        err_sys("fork error");

    else if (0 == pid) {
        if(execlp("echoall",
              "echoall", "only 1 arg", (char *) 0) < 0)
            err_sys("execlp error");
    }

    exit(0);

}

测试代码如下

$ ./execExample
argv[0]: echoall #execle执行echoall  
argv[1]: myarg1
argv[2]: MY ARG2
USER=unknown
PATH=/tmp
argv[0]: echoall #execlp执行echoall
$ argv[1]: only 1 arg
LC_PAPER=en_US.UTF8
HOME=/home/klose
# ...... 其他各种环境变量 
_=./execExample

shell提示符号 '$' 出现在 第二个exec 打印 "echo all" 和 "only 1 arg" 之间

这是因为父进程并不等待该子进程结束

       观察的tip(1)程序，这个程序连接到一个远程系统，或者是直接连接，或者是拨号一个调制解调器

       当tip使用调制解调器时，它必须通过使用锁文件来独占使用它
       此锁文件与UUCP程序共享，因为这两个程序可能要同时使用同一调制解调器

对tip的工作步骤说明如下:

1. tip程序文件是由用户 uucp 拥有的，并且其 设置-用户-ID位 已设置。当exec此程序时，则关于用户ID得到下列结果:
   • 实际用户ID = 我们的用户ID
   • 有效用户ID = uucp
   • 保存设置-用户-ID = uucp
2. tip存取所要求的锁文件。这些 锁文件 是由 uucp的用户所拥有的 ，因为 有效用户ID 是 uucp ，所以tip 可以存取这些锁文件
3. tip执行setuid(getuid())。因为 tip不是超级用户进程 ，所以这 仅仅改变有效用户ID 。此时得到：
   • 实际用户ID = 我们的用户ID(未改变)
   • 有效用户-ID = 我们的用户ID(改变) ： 这就意味着能存取的只有我们通常可以存取的，没有额外的许可权
   • 保存设置-用户-ID=uucp(未改变)
4. 当执行完所需的操作后，tip执行setuid(uucpuid)，其中 uucpuid 是 用户uucp的数值用户ID (tip很可能在起动时调用geteuid，得到uucp的用户ID，然后将其保存起来，我们并不认为tip会搜索口令文件以得到这一数值用户ID)。因为 setuid的参数 等于 保存的设置-用户-ID ，所以这种 调用是许可的 (这就是 为什么需要保存的设置-用户-ID的原因 )。现在得到:
   • 实际用户ID = 我们的用户ID(未改变)
   • 有效用户ID = uucp
   • 保存设置-用户-ID = uucp(未改变)
5. tip现在可 对其锁文件进行操作以释放 它们，因为 tip的有效用户ID 是 uucp

       以这种方法使用保存的设置-用户-ID：

       在进程的开始和结束部分就可以使用由于程序文件的”设置用户ID而得到的额外优先权“， 但是进程在其运行的大部分时间只具有”普通的许可权“

       如果进程不能在其结束部分 切换回保存的设置-用户-ID，那么就不得不在全部运行时间都保持额外的许可权，这无疑会造成安全问题

       如果在tip运行时生成一个shell进程，先fork，然后exec将发生什么？

• 因为 实际用户ID 和 有效用户ID 都是 我们的普通用户ID (上面的第(3)步)，所以 该shell没有额外的许可权
• 它 不能存取tip运行时设置成 保存的设置-用户-ID uucp ，因为 该shell所保存的设置-用户-ID 是由 exec shell进程 复制 tip进程的有效用户ID 而得到的

• 所以在执行exec的子进程中：

  • 实际用户ID = 我们的用户ID
  • 有效用户ID = 我们的用户ID
  • 保存设置-用户-ID = 我们的用户ID

  对于进程特权的改变，应遵循“使用能完成工作的最小特权”的原则，以避免用户进程越权操作：
  
  1. 在不需要设置-用户-ID带来的权限时，使用setuid(getuid()) “降低有效用户ID”的特权
  
  2. getuid和geteuid函数只能获得实际用户ID和有效用户ID的当前值，
    而不能获得所保存的设置-用户-ID的当前值。必须在降低权限前通过”调用geteuid”然后 “保存”
  
  3. 再次需要高级权限的时候，可以通过“setuid(保存的euid)来恢复”
  
  4. 在“子进程执行exec之前”，应“setuid(getuid())”以避免设置-用户-ID引起的”特权传递“
  
  5. 如果程序的设置-用户-ID为 root，以超级用户特权调用setuid就会设置所有三个用户ID，慎用！！！