Linux操作系统实验入门：终端、fork、进程调度与系统调用

简介：面向软件工程及计算机专业学生与操作系统课程学习者，这份西南交通大学操作系统实验报告（评分A，95分）可作为Linux实验课配套参考与复盘材料。内容围绕Linux环境与C程序调试展开：熟悉用户界面、目录结构与Shell常用命令，练习重定向和管道，使用vi或gedit编辑、gcc编译并用gdb调试；进而通过/proc文件观察cpuinfo、version、stat、uptime，并编程读取meminfo、loadavg、interrupts、filesystem，理解内核状态与内存、负载等机制。报告还覆盖软中断通信、FCFS与RR进程调度验证、线程同步等实验，按实验目的、内容、步骤与总结组织，便于对照课程要求梳理原理和排错思路。资源包为1个docx文档，约1.48MB，轻量便于查阅；目前已有403人学习，适合需要完成实验报告、复习Linux系统机制或准备课程验收的读者参考。

1. 先澄清一个误解：操作系统实验不是背概念，是学会跟系统打交道

一个刚学完 C 语言的同学，第一次看到"操作系统实验报告"这七个字，脑子里冒出来的多半是：是不是又要背一堆概念？是不是要读很多内核代码？我当初也这么想，直到真正把第一个小实验跑起来才发现，它更像一份"拆机手册"——不要求你会造发动机，只要求你能打开发动机盖，看清里面每个零件在干什么。这份 Linux 操作系统实验报告来自某高校软件工程专业的操作系统课程，从熟悉终端、编译 C 程序开始，一路做到信号通信、进程调度、线程同步、内存管理、系统调用和缺页统计，七八个小实验像七八次拆机，每个都对应课本上一章内容。它适合完全没碰过 Linux、只会写点 C 的零基础新手，也适合想弄明白"程序跑起来以后系统到底做了什么"的人。

2. 七个小实验拼出一张地图：先搞清楚学什么，再决定从哪下手

2.1 为什么这门课值得花时间：你写的每一行代码最后都跑在它上面

很多人学编程学到大二会产生错觉，以为自己写的是"程序"，其实写的是"给操作系统看的申请书"。你 malloc 一块内存，是操作系统分给你的；你 fork 一个进程，是操作系统帮你复制的；你 printf 一句中文，背后是系统调用把数据交给驱动、再由驱动交给屏幕。平时这些都被语言和库藏起来了，你只看到结果，看不到过程。操作系统实验做的事，就是把这些"被藏起来的部分"一件件拆开给你看。

这件事的实际收益有三层。最浅的一层是课程本身：这类实验通常占平时分的大头，报告写得好不好、结果跑没跑出来，直接影响成绩，这份报告在课程里拿到了 95 分，它本身就是一份可以参考的答题样本。中间一层是后续课程：编译原理、计算机网络、数据库，只要往下学，迟早会遇到"进程""文件描述符""内存页"这些词，早一点在 Linux 里见过它们长什么样，后面就不是从零开始。最实用的一层是工作习惯：绝大多数服务器、云主机、嵌入式设备跑的都是 Linux，你会用终端、会看进程、会读/proc，等于提前拿到了进入真实开发环境的钥匙。

我第一次学的时候也犯过一个错，把实验当成"抄代码—跑通—截图"三步流程，结果实验做完了，问他 fork 返回 0 是什么意思，答不上来。操作系统课的坑就在这里：跑通很快，理解很慢。报告里那句"因为代码是现成的，因此代码也就只是做到了读懂而已"，说的正是这种状态。所以我建议你从一开始就换个姿势：每跑通一个实验，逼自己合上报告，把代码默写一遍，再对着输出解释一遍每一步发生了什么。慢，但一次顶三次。

2.2 八个实验各在解决什么问题：一份对照表

报告里的实验编号有个小问题，第一个和第二个都叫"实验 1"，新手翻目录容易懵，其实它们是两件事。我把整份报告按"你在做什么 / 对应课本哪个概念"整理成一张表，先看全局再看细节，心里就不慌了。

看表可能有同学会问，为什么是这个顺序。因为它是按照"从外面看"到"从里面改"排的。前两个实验你站在系统外面，只负责观察和使用；中间的信号、调度、同步、内存，是站在进程的角度看系统怎么服务你；最后两个系统调用和缺页统计，才开始动内核，是整份报告里最硬的部分。你按顺序做，难度是平滑上升的；你要是跳着从系统调用开始，大概率第一天就想放弃。

再说透一点每个实验的价值。软中断那个实验，看起来只是按个组合键让几个进程退出，但它把"异步"这件事演给你看了：父进程并不知道子进程什么时候结束，它只能等信号。这个模型后面会反复出现，网络编程里的回调、前端的事件监听，本质都是同一套思路。进程调度实验里 FCFS（先来先服务）和 RR（时间片轮转）的差别，用一句话概括就是"排队买饭"和"每人只准买三十秒"，你先在小数据量上算出平均周转时间，再回头看教材里的公式，公式就不再是天书。线程同步实验的核心不是会写锁，而是亲眼见到"不加锁会出错、加了锁结果就对了"这个对比，没有这个对比，你永远记不住临界区为什么危险。

2.3 第一遍怎么用这份报告：抄、改、讲

拿到一份带完整代码和结果的报告，最省事的用法是复制粘贴，最没用的用法也是复制粘贴。我给新手的路径是三步，每一步都别跳。

第一步叫"抄"，但不是无脑抄。照着报告把代码敲进自己的机器，一个字一个字敲，不要复制。敲的过程你会自然注意到signal(SIGQUIT, stop)里传的是函数名而不是函数调用，会注意到wait_mark是个全局变量，这些细节复制粘贴是看不见的。敲完编译，如果一次就过，说明环境没问题；如果报错，先别改代码，先看错误信息第一行，八成是头文件或者编译命令的问题。

第二步叫"改"。每个实验至少改一处：把父进程创建两个子进程改成三个，把时间片从固定值改成从命令行参数读，把打印的中文改成带时间戳的格式。改完再跑，看结果怎么变。这一步是整份报告里性价比最高的部分，因为它强迫你理解每一行代码的作用，而不是把它当咒语。

第三步叫"讲"。找个人（哪怕是空气），用三分钟把这个实验讲清楚：它要解决什么问题、代码里哪一行是关键、结果为什么长这样。讲不下去的地方，就是你还没懂的地方，回去补。报告里每个实验后面都有"实验总结"，作者写了不少自己踩的坑，比如虚拟机网络连不上、Windows 里写好的代码拷进 Linux 报错找不到fork，这些总结比正文更值得读，因为它们是失败路径的记录，而失败路径往往比成功路径更有信息量。

3. 迈出第一步：把终端当成新同桌，先学会这几条命令

3.1 为什么第一步是终端，而不是先装个顺手的 IDE

新手最容易产生的第一个抵触是：都什么年代了，为什么还要在黑框框里敲命令。我理解这种感受，当年我也想过"我在 Windows 里有编辑器，写完传进去不就行了"。报告里正好记了这件事：作者一开始就是这么干的，结果代码在编辑器里一直报错，因为那个环境里根本没有fork()这个函数，最后还得老老实实传进 Linux 里编译验证。

原因不复杂。图形界面是给人看的，终端是给系统看的，两者信息密度差一个数量级。你在图形界面里点开一个文件夹，看到的是图标和名字；你在终端里ls -l，看到的是权限、所有者、大小、修改时间、软硬链接，一行顶十行。而且服务器上通常没有图形界面，你以后连的机器只有一个黑框，现在不习惯，以后更难受。

入门的话，建议先用虚拟机装一个常见的 Linux 发行版，装完做三件事：打开终端、输入whoami看自己是谁、输入pwd看自己在哪。这三条命令没有任何风险，但能立刻给你一个"我在系统里有个位置"的实感。报告里提到的三种网络模式（桥接、NAT、仅主机）不用一开始就搞懂，默认用 NAT 就行，它能上网、也不容易和别的设备撞地址，等哪天网络出问题了再回头补这一课。

3.2 六条命令先跑顺：cd、ls、ps、chmod、重定向、管道

命令不用背一整个手册，先掌握六类，覆盖日常八成操作。

cd /proc # 切换目录，后面跟路径；只写 cd 就回到自己的家目录 ls -l # 列目录，-l 是长格式，能看见权限、大小、时间 ps -ef # 看系统里所有进程，-e 全部，-f 完整格式（能看到父子关系） chmod 644 demo.c # 改权限：6 读写、4 只读、4 只读，依次对应所有者/组/其他人 ls /proc > list.txt # > 把输出写进文件，屏幕上不再显示 cat /proc/cpuinfo | grep "model name" | head -3 # | 把上一条的输出交给下一条处理

前四条是"我在哪、有什么、谁在跑、能不能改"，后两条是重定向和管道。重定向和管道这两个词听着唬人，其实就是把数据流换个方向：默认情况下命令的输出流向屏幕，>把它改道流进文件，|把它改道流进另一个命令。理解这一点，后面/proc实验里那些"读文件看系统状态"的操作就变得非常自然，因为系统状态本身就是以文件形式暴露出来的，你只是在读文件。

这里有个小细节值得单独说：ps -ef的输出里有一列 PPID，是父进程号。这个字段在信号实验和进程调度实验里会反复用到，你现在多看一眼，后面就少卡一次。我建议你养成一个习惯，每跑一个多进程的程序，就开另一个终端敲一次ps -ef | grep 你的程序名，看看进程树长什么样。这个习惯看着笨，但它是理解"进程"这个概念最快的办法。

3.3 第一次编译：从 vim 敲到 gcc 出可执行文件

环境熟悉了，就可以写第一个 C 程序。报告里给的是一个接收命令行参数的小程序，很适合入门，因为输出短、结果可预期。

#include <stdio.h> int main(int argc, char *argv[]) { printf("参数个数：%d\n", argc); /* argc 含程序名本身，所以至少是 1 */ for (int i = 0; i < argc; i++) printf("第 %d 个参数：%s\n", i, argv[i]); /* argv[0] 是程序名，后面才是你传的 */ return 0; }

这段代码不长，但把 C 程序的两个关键入口参数讲清楚了：argc是数量，argv是内容。很多人第一次见char *argv[]会懵，其实它就是"一串字符串"，argv[0]永远是你运行的程序名。

写完之后的流程是固定的四步，建议一开始就按这个顺序敲，别图快：

vim argc.c # 打开或新建文件，按 i 进入编辑模式，写完按 Esc 退出编辑模式 # 再输入 :wq 回车保存退出；想放弃修改就 :q! gcc argc.c -o argc # 编译，-o 指定输出文件名，不写就默认叫 a.out ./argc hello linux # 运行，./ 表示"当前目录下的这个文件"，后面是传给程序的参数

gcc这一行是新手第一次真正翻车的地方。-o后面跟的是你想要的可执行文件名，不是源文件名，写错顺序会得到一个奇怪的结果。如果编译没有任何输出，恭喜你，在 Unix 的哲学里"没有消息就是好消息"。如果报错，先看第一行，error:是致命错误必须改，warning:是警告可以先放着，但别养成无视警告的习惯，很多玄学问题都是警告攒出来的。

跑通之后，把./argc hello linux换成./argc再跑一次，看argc变成几。再做一次重定向./argc a b > out.txt，打开out.txt看看内容是不是和屏幕上一样。这两步花不了五分钟，但能让你对"参数"和"输出流向"这两件事形成肌肉记忆，后面实验里满屏的printf调试就不会手忙脚乱。

4. 第一个能跑的例子：用 fork 亲手造一个子进程

4.1 fork 到底干了什么：一个"分叉路口"的类比

如果说终端是操作系统实验的门槛，那fork()就是门槛上的那道横杆。信号、调度、同步，后面几乎所有实验都要先创建进程，而 Linux 里创建进程的标准动作就是一次fork()。

你可以把它想成一个分叉路口。程序本来只有一条路往前走，走到fork()这个位置时，路口突然分成两条：原来的那条继续走，同时多出一条一模一样的岔路，上面站着一个和你长得一模一样的自己，连手里拿的纸条（变量值）都一样。唯一的区别是，路口会给两个人各发一张小卡片，上面写着不同的编号：岔路上的那个拿到 0，原来那个拿到新人的进程号。所以代码里判断"我是不是子进程"，靠的就是fork()的返回值是不是 0。

这个模型解释了新手最常问的两个问题。第一，为什么fork()之后printf会打印两次？因为确实有两个进程在跑同一段代码。第二，为什么父进程里pid是个正数，子进程里是 0？因为父进程需要知道"我创建的那个孩子叫什么名字"，而子进程只需要知道"我是孩子"。理解了这两点，后面信号实验里"父进程杀子进程"的写法就顺理成章了，kill(pid, 16)里的pid就是当初fork()返回的那个正数。

4.2 十几行代码跑通父子进程

报告里信号实验的核心代码有几十行，还夹着两个子进程和一个孙进程，第一次看容易劝退。入门的话，建议先把代码精简到最小，只保留父、子两条线，跑通再往上加。

#include <stdio.h> #include <unistd.h> /* fork、sleep、getpid 都在这里 */ #include <sys/types.h> /* pid_t 类型的定义 */ int main(void) { pid_t pid; pid = fork(); /* 关键一行：执行到这里，一个进程变成两个 */ if (pid < 0) { /* 返回负值说明创建失败，常见原因是进程数到上限 */ perror("fork"); return 1; } if (pid == 0) { /* 返回 0：这段只有子进程会进来 */ printf("我是子进程，pid = %d，我爸是 %d\n", getpid(), getppid()); } else { /* 返回正数：这段只有父进程会进来，值就是子进程的 pid */ printf("我是父进程，pid = %d，我创建了 %d\n", getpid(), pid); sleep(1); /* 停一秒，让子进程先打印，避免两个输出糊在一起 */ } return 0; }

编译和运行还是老三样，命令和上一章完全一致，不需要额外链接任何库：

gcc fork_demo.c -o fork_demo ./fork_demo

跑之前先猜一下输出顺序，跑完再对照。大多数人的第一次运行结果都是父进程先打印，因为父进程本来就占据 CPU，fork()返回后它接着往下走，子进程要等调度。加sleep(1)的目的就是人为把父进程按住一秒，让子进程先说话，这样输出看起来符合直觉，也顺便让你体会一次"进程调度是系统说了算，不是代码说了算"。

4.3 跑完之后看什么：进程号、父子关系、谁先谁后

程序跑完不算完，接下来三件事才是真正学到东西的部分。

第一件，看进程号。getpid()拿到的是自己的号，getppid()拿到的是父亲的号。父进程打印出的那个pid值，应该和子进程打印的getpid()完全一致，同时也等于子进程的getppid()。如果对不上，说明你把返回值理解反了。这个对应关系是后面所有进程实验的基础，我建议你拿笔在纸上画一下两个进程的号，画一次就再也不会混。

第二件，看父子关系。另开一个终端，在程序运行期间敲ps -ef | grep fork_demo，你会看到两行，一行是父，一行是子，子进程那行倒数第二列就是父进程号。这时候你再看代码里的fork()，感受会完全不一样——刚才那个抽象的分叉路口，现在在系统里是两条真实存在的记录。

第三件，看退出状态。把sleep(1)删掉再跑十次，你会发现输出顺序有时候是反的。这不是 bug，是正常现象，因为两个进程谁先被调度完全由系统决定。新手遇到这种情况往往会以为代码写错了，然后开始改来改去，越改越乱。正确的做法是接受它：并发程序的输出顺序本来就不确定，想让它确定，就得用wait()或者加锁，而这两样东西正是后面信号实验和线程同步实验要解决的问题。你在这里先碰一次，后面就有心理准备。

顺带说一句报告里的第二个信号实验，它多了一层"孙进程"：子进程再fork()一次。代码看着复杂，其实是同一个模型套了两层，父等子、子等孙，按 Ctrl+\ 之后从最末端开始依次退出。你把上面这十几行吃透，再看那段代码就只是"多看了一层"，不会觉得是全新的东西。

5. 新手最容易踩的五个坑：对照现象找原因

5.1 环境和工具类的坑：装好了不等于能用

坑一：虚拟机里网络一直连不上，ping 谁都不通。

现象是系统装好了、界面也正常，但一打开浏览器就转圈，终端里ping也没反应。原因多半出在虚拟网络模式上，默认配置有时候和宿主机的网络环境冲突。解决办法是先确认当前用的是哪种模式，改成 NAT 模式再试，因为 NAT 模式下虚拟机会自己拿一个地址、通过宿主机出去，不容易和局域网里其他设备撞车。如果还不行，就检查虚拟机设置里网卡是不是被禁用了。这类问题不用深究原理，先让它通，等后面实验需要互相访问时再回来看桥接和仅主机模式的区别。

坑二：在 Windows 里写好 C 代码，拷进 Linux 编译报错，说找不到fork。

现象是代码在你熟悉的编辑器里一片红，提示函数未声明，但同样的代码放进 Linux 就能编译。原因是fork()这类函数属于 Unix 系统调用，Windows 的 C 运行库根本没有它，编辑器只是如实告诉你"我不认识这个词"。解决办法很简单，不要在 Windows 里验证这类代码，直接在 Linux 里写、在 Linux 里编译。如果你实在想在本地写，就记住一点：写完不要看编辑器的红色波浪线，直接传过去编译，编译器说了算。

坑三：gcc敲下去没有任何提示，但运行时报"没有那个文件或目录"。

现象是编译命令执行完，屏幕上安安静静，接着./a.out却提示找不到文件。原因通常是你用了-o指定了名字，却还去运行a.out；或者编译的源文件和当前目录里的不是同一个。解决办法是ls一下当前目录，看看生成的可执行文件到底叫什么，然后按名字运行。这个坑很小，但新手一天能踩三次，养成"编译完先ls一眼"的习惯就没事了。

5.2 代码与结果类的坑：跑通了不等于对了

坑四：按下 Ctrl+\ 之后，进程没退出，终端卡住不动。

现象是程序跑起来了，按了组合键，屏幕上没有任何新输出，光标停在那里，只能再开一个终端kill掉。原因有两个方向：一是信号根本没送到，比如程序在前台跑但终端焦点在别的窗口；二是送到了，但子进程把SIGQUIT设成了忽略，只能靠父进程转发的那个自定义信号退出，而转发逻辑写错了。解决顺序是先确认信号有没有发出去，用ps -ef看进程还在不在；再在每一处signal()后面加一句打印，看哪一步没有执行。这类问题最忌讳盯着代码硬看，加两行打印比看半小时快。

坑五：多个进程同时printf，输出糊成一团，两句话粘在一行。

现象是本来应该各占一行的输出，变成了半行加半行。原因是多个进程共享同一个标准输出，谁先写谁后写没有保证，写到一半被切走就糊了。解决办法是给输出加锁，报告里用的是lockf(1, 1, 0)和lockf(1, 0, 0)这一对，一个加锁一个解锁，夹住printf就行。这里有个顺序上的讲究：加锁和解锁必须成对出现，中间不要return或者exit，否则锁一直不释放，别的进程就永远等下去。我第一次写的时候就在中间加了个提前返回，结果程序挂在那里，排查了很久才发现是锁没解。

坑六：读/proc里的文件，内容一大堆，看不懂哪个是有用的。

现象是cat /proc/meminfo出来几十行，每行都是"某某: 数值 kB"，不知道看哪个。原因是你把它当普通文本读了，其实这些文件是内核数据结构的一份"投影"，每个字段都有固定含义。解决办法是先带着问题去读，比如你只想回答"现在内存剩多少"，那就只看MemAvailable这一行，其他先跳过。报告里观察cpuinfo、version、stat、uptime的顺序也是这个思路：先看单个字段，再写程序把它提取出来。不要一上来就想全部读懂，那是不可能的，也没必要。

这五个坑的共同点是：它们都不在教材里，但每个新手都会遇到至少两个。遇到的时候别怀疑自己笨，这类问题属于环境问题和顺序问题，跟智商无关，跟你有没有提前知道有关。

6. 下一步学什么：从照着做，到能自己改

跑通第一个例子之后，很多人会卡在一个状态：报告里的代码能看懂，但让我自己写就写不出来。这个状态很正常，它说明你缺的不是知识，是"改动量"。我给的学习路径是按顺序补三块，每块都配一个具体动作。

第一步的关键是"改动量要小但必须动"。很多人一上来就想重写整个实验，结果卡在编译错误里出不来。从"两个子进程变三个"这种改动开始，一次只动一个地方，改完立刻跑，跑完立刻验证，节奏就对了。

第二步要重点理解一件事：printf不是系统调用，它下面还有一层缓冲和write。你把同一个字符串分别用printf和write(1, ...)输出，再对比重定向到文件后的结果，就能看出缓冲的存在。这个认知一旦建立，后面看任何涉及 I/O 的代码都不会迷糊。这也是我建议在系统调用实验里多花时间的原因，那一章看着枯燥，但它是把"用户态"和"内核态"分开的那道线。

第三步听起来玄，其实很实在：找一段你似懂非懂的代码，不给它加任何功能，只给它加注释，每一行都写清楚"这行在执行时，系统里发生了什么"。写不出来的地方，就是你该去查的地方。这个练习比抄十遍代码有用。

最后说个我自己的习惯。当年做信号实验，我图省事，程序跑完直接关终端，从来不检查有没有残留进程，结果后面做进程调度实验时，机器上堆了十几个没退出的进程，ps一屏都刷不完，排查了半天才发现是自己留下的。从那以后我每次跑带fork的程序，收尾都强制走一遍ps -ef | grep 程序名，确认干净了再继续。这个动作只要五秒钟，但帮我省掉过好几次莫名其妙的"玄学"故障。这份报告里那些血泪经验式的总结，价值也在这儿——它记录的不是正确答案，是别人替你踩过的坑。希望帮到你。

本文还有配套的精品资源，点击获取