有了系统调用,公司就能批量接项目了。问题是,公司借了这么多项目,应该怎么管理呢?答案是通过进程管理
linux上有多种创建进程的方式,比如通过命令,还可以通过系统调用来创建一个进程
用系统调用创建进程
在 Linux 上写程序和编译程序,也需要一系列的开发套件。
(1)执行如下命令按照环境:
yum -y groupinstall "Development Tools"
- yum 提供二种安装软件的方式:
- yum install 它安装单个软件,以及这个软件的依赖关系
- yum groupinstall 它安装一个安装包,这个安装包包涵了很多单个软件,以及单个软件的依赖关系。
- Development tools 这是一个可以给开发编译运维的配置基本初始环境的工具。
yum groupinfo "Development tools"
Loaded plugins: fastestmirror
There is no installed groups file.
Maybe run: yum groups mark convert (see man yum)
Loading mirror speeds from cached hostfile
Group: Development Tools
Group-Id: development
Description: A basic development environment.
Mandatory Packages: #提示有必要的安装包
+autoconf
+automake
binutils
+bison
+flex
gcc
+gcc-c++
gettext
+libtool
make
patch
pkgconfig
+redhat-rpm-config
+rpm-build
+rpm-sign
Default Packages: #默认的安装包
+byacc
+cscope
+ctags
+diffstat
.....太多安装包,而且是组合包
(2)用Vim创建一个文件,就可以开始编写代码了
编写代码
我们先来创建一个文件,里面用一个函数封装通用的创建进程的逻辑,名字叫 process.c,代码如下:
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <unistd.h>
extern int create_process (char* program, char** arg_list);
int create_process (char* program, char** arg_list)
{
pid_t child_pid;
child_pid = fork ();
if (child_pid != 0)
return child_pid;
else {
execvp (program, arg_list);
abort ();
}
- 这里面用到了fork,根据fork的返回值不同,父进程和子进程就此分道扬镳了
- 在子进程里面,我们需要通过execvp运行一个新的程序
接下来我们创建第二个文件createprocess.c,调用上面这个函数:
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <unistd.h>
extern int create_process (char* program, char** arg_list);
int main ()
{
char* arg_list[] = {
"ls",
"-l",
"/etc/yum.repos.d/",
NULL
};
create_process ("ls", arg_list);
return 0;
}
- 在这里,我们创建的子程序运行了一个最最简单的命令 ls
编译成二进制格式
程序写完了是不是就能马上运行了呢?
- 当然不是,因为CPU是不能执行文本文件里面的指令的,这些指令只有人才能看懂,CPU能够执行的命令是二进制的,比如“0101”这种
- 所以这些指令还需要翻译一下,这个翻译的过程就叫做编译。
编译好的二进制文件相当于项目执行计划书,项目执行数应该有统一的格式,这样才能保证无论项目交到哪个项目组里面,都能以固定的流程执行。
在linux下面,二进制的程序也要有严格的格式,这个格式叫做ELF(Executeable and Linkable Format,可执行与可链接格式)。根据编译的结果不同,分为不同的格式。
那,文本文件是如何编译成二进制格式的呢?
- 执行下面命令编译这两个文件(编译好的二进制文件里面,应该是代码,还有一些全局变量、静态变量等等):
gcc -c -fPIC process.c
gcc -c -fPIC createprocess.c
-
在编译的过程中,先做预处理工作,比如将头文件嵌入到正文中,将定义的宏展开,然后就是真正的编译过程,最终编译称为.o文件,这就是ELF的第一种格式,可重定向文件。这个文件的格式是这样的:
- ELF 文件的头是用于描述整个文件的。这个文件格式在内核中有定义,分别为 struct elf32_hdr 和 struct elf64_hdr。下面是一个个的section(节)
- .text:放编译好的二进制可执行代码
- .rodata:只读数据,例如字符串常量、const 的变量
- .data:已经初始化好的全局变量
- .bss:未初始化全局变量,运行时会置 0
- .symtab:符号表,记录的则是函数和变量
- .strtab:字符串表、字符串常量和变量名
- 这些节的元数据信息也需要有一个地方保存,就是后面的节头部表(Section Header Table)在这个表里面,每一个 section 都有一项,在代码里面也有定义 struct elf32_shdr 和 struct elf64_shdr。
-
(补充:为啥这里只有全局变量呢?因为局部变量是存放在栈里面的,是程序运行过程中随时分配文件,随时释放的,而现在程序压根就没有启动,这里只是二进制文件)
-
什么叫做可重定位呢?
- 编译好的代码和变量,将来加载到内存的时候,都是要加载到一定位置的。比如说,调用一个函数,其实就是跳转到函数所在代码位置指向;修改一个全局变量,必须找到变量的位置才能修改。但是现在这个时候,还是.o文件,不是一个可以直接运行的程序,这里面只是部分代码片段。
- 比如这里的create_process函数,将来被谁调用,在哪里调用都不清楚,更不用说确定位置了。所以,.o里面的位置是不确定的,但是必须是可重定位的,因为他将来是要做函数库的,就是一块砖,哪里需要哪里搬,搬到哪里就重新定位这些代码、变量的位置。
- 有的section比如.rel.text, .rel.data就和重定位有关。比如createprocess.o中里面调用了createprocess函数,但是这个函数在process.o里面,也就是说createprocess不知道被调用的函数的位置,所以只好在.rel.text里面标注,这个函数是需要重定位的
-
要想让createprocess函数作为库函数被调用,不能以.o的形式存在,而是要形成库文件,最简单的类型就是静态链接库.a 文件(Archives),仅仅将一系列对象文件(.o)归档为一个文件,使用命令ar创建:
ar cr libstaticprocess.a process.o
- 虽然这里 libstaticprocess.a 里面只有一个.o,但是实际情况可以有多个.o。当有程序要使用这个静态连接库的时候,会将.o 文件提取出来,链接到程序中。
gcc -o staticcreateprocess createprocess.o -L. -lstaticprocess
- 在这个命令里,-L 表示在当前目录下找.a 文件,-lstaticprocess 会自动补全文件名,比如加前缀 lib,后缀.a,变成 libstaticprocess.a,找到这个.a 文件后,将里面的 process.o 取出来,和 createprocess.o 做一个链接,形成二进制执行文件 staticcreateprocess。
- 这个链接的过程,重定位就起作用了,原来 createprocess.o 里面调用了 create_process 函数,但是不能确定位置,现在将 process.o 合并了进来,就知道位置了。
- 形成的二进制文件叫可执行文件,是 ELF 的第二种格式,格式如下:
- 这个格式和.o文件大致相似,但是分成一个个的section,并且被节头表描述。
- 只不过这些section是多个.o文件合并过的。但是这个时候,这个文件已经是马上就可以加载到内存里面执行的部分了,因而这些section被分成了需要加载到内存里面的代码段、数据段和不需要加载到内存的部分,将小的section合并成了大的段segment,并且在最前面加一个段头表(Segment Header Table)。在代码里面的定义为 struct elf32_phdr 和 struct elf64_phdr,这里面除了有对于段的描述外,最重要的是p_vaddr,这个是这个段加载到内存的虚拟地址
- 在 ELF 头里面,有一项 e_entry,也是个虚拟地址,是这个程序运行的入口。
当程序运行起来之后,就是下面这个样子:
# ./staticcreateprocess
# total 40
-rw-r--r--. 1 root root 1572 Oct 24 18:38 CentOS-Base.repo
......
- 静态链接库一旦链接进去,代码和变量的section都合并了,因而程序运行的时候,就不依赖于这个库是否存在
- 缺点是相同的代码段,如果被多个程序使用的话,在内存里面就有多份,而且一旦静态链接库更新了,如果二进制执行文件不重新编译,也不随着更新
因而就出现了另一种动态链接库(Shared Libraries),不仅仅是一组对象文件的简单归档,而是多个对象文件的重新组合,可以被多个程序共享:
gcc -shared -fPIC -o libdynamicprocess.so process.o # 将process.o变成libdynamicprocess.so
- 当一个动态链接库被链接到一个程序文件中的时候,最后的程序文件并不包括动态链接库中的代码,而仅仅包括对动态链接库的引用,并且不保存动态链接库的全路径,仅仅保存动态链接库的名称
gcc -o dynamiccreateprocess createprocess.o -L. -ldynamicprocess
- 当运行这个程序的时候,首先寻找动态链接库,然后加载它。默认情况下,系统在 /lib 和 /usr/lib 文件夹下寻找动态链接库。如果找不到就会报错,我们可以设定 LD_LIBRARY_PATH 环境变量,程序运行时会在此环境变量指定的文件夹下寻找动态链接库。
# export LD_LIBRARY_PATH=.
# ./dynamiccreateprocess
# total 40
-rw-r--r--. 1 root root 1572 Oct 24 18:38 CentOS-Base.repo
......
动态链接库,就是 ELF 的第三种类型,共享对象文件(Shared Object)。用的很少,就不解析啦
运行程序为进程
知道了ELF这个格式,这个时候它还是个程序,那怎么把这个文件加载到内存里面呢?
- 在内核中,有这样一个数据结构,用来定义加载二进制文件的方法:
struct linux_binfmt {
struct list_head lh;
struct module *module;
int (*load_binary)(struct linux_binprm *);
int (*load_shlib)(struct file *);
int (*core_dump)(struct coredump_params *cprm);
unsigned long min_coredump; /* minimal dump size */
} __randomize_layout;
- 对于ELF文件,有着对应的实现
static struct linux_binfmt elf_format = {
.module = THIS_MODULE,
.load_binary = load_elf_binary,
.load_shlib = load_elf_library,
.core_dump = elf_core_dump,
.min_coredump = ELF_EXEC_PAGESIZE,
};
- 从上面可以看到,用到了load_elf_binary ,而我们加载内核镜像的时候,用的也是这种格式,当时的过程是这样的:do_execve->do_execveat_common->exec_binprm->search_binary_handler。do_execve调用如下:
SYSCALL_DEFINE3(execve,
const char __user *, filename,
const char __user *const __user *, argv,
const char __user *const __user *, envp)
{
return do_execve(getname(filename), argv, envp);
}
exec 这个系统调用最终调用的 load_elf_binary。
ps:exec 比较特殊,它是一组函数:
- 包含 p 的函数(execvp, execlp)会在 PATH 路径下面寻找程序;
- 不包含 p 的函数需要输入程序的全路径;
- 包含 v 的函数(execv, execvp, execve)以数组的形式接收参数;
- 包含 l 的函数(execl, execlp, execle)以列表的形式接收参数;
- 包含 e 的函数(execve, execle)以数组的形式接收环境变量。
在上面 process.c 的代码中,我们创建 ls 进程,也是通过 exec
进程树
既然所有的进程都是从父进程fork过来的,那总归有一个祖先进程,那就是系统启动的init进程
- 在解析 Linux 的启动过程的时候,1 号进程是 /sbin/init。如果在 centOS 7 里面,我们 ls 一下,可以看到,这个进程是被软链接到systemd的:
/sbin/init -> ../lib/systemd/systemd
- 系统启动之后,init进程会启动很多daemon进程,为系统运行提供服务,然后就是启动getty,让用户登录,登录后运行shell,用户启动的进程都是通过shell运行的,从而形成了一棵进程树
我们可以通过 ps -ef 命令查看当前系统启动的进程,我们会发现有三类进程。
[root@deployer ~]# ps -ef
UID PID PPID C STIME TTY TIME CMD
root 1 0 0 2018 ? 00:00:29 /usr/lib/systemd/systemd --system --deserialize 21
root 2 0 0 2018 ? 00:00:00 [kthreadd]
root 3 2 0 2018 ? 00:00:00 [ksoftirqd/0]
root 5 2 0 2018 ? 00:00:00 [kworker/0:0H]
root 9 2 0 2018 ? 00:00:40 [rcu_sched]
......
root 337 2 0 2018 ? 00:00:01 [kworker/3:1H]
root 380 1 0 2018 ? 00:00:00 /usr/lib/systemd/systemd-udevd
root 415 1 0 2018 ? 00:00:01 /sbin/auditd
root 498 1 0 2018 ? 00:00:03 /usr/lib/systemd/systemd-logind
......
root 852 1 0 2018 ? 00:06:25 /usr/sbin/rsyslogd -n
root 2580 1 0 2018 ? 00:00:00 /usr/sbin/sshd -D
root 29058 2 0 Jan03 ? 00:00:01 [kworker/1:2]
root 29672 2 0 Jan04 ? 00:00:09 [kworker/2:1]
root 30467 1 0 Jan06 ? 00:00:00 /usr/sbin/crond -n
root 31574 2 0 Jan08 ? 00:00:01 [kworker/u128:2]
......
root 32792 2580 0 Jan10 ? 00:00:00 sshd: root@pts/0
root 32794 32792 0 Jan10 pts/0 00:00:00 -bash
root 32901 32794 0 00:01 pts/0 00:00:00 ps -ef
- PID 1 的进程就是我们的 init 进程 systemd,PID 2 的进程是内核线程 kthreadd,这两个我们在内核启动的时候都见过。其中用户态的不带中括号,内核态的带中括号。
- 接下来进程号依次增大,但是你会发现:
- 所有带中括号的内核态的进程,祖先都是 2 号进程。
- 用户态的进程,祖先都是 1 号进程。
- tty 那一列,是问号的,说明不是前台启动的,一般都是后台的服务。
总结
这一节我们讲了一个进程从代码到二进制到运行时的一个过程,我们用一个图总结一下。
- 我们首先通过图右边的文件编译过程,生成 so 文件和可执行文件,放在硬盘上
- 下图左边的用户态的进程 A 执行 fork,创建进程 B,在进程 B 的处理逻辑中,执行 exec 系列系统调用。
- 这个系统调用会通过 load_elf_binary 方法,将刚才生成的可执行文件,加载到进程B 的内存中执行。