加餐福利 课后思考题答案合集¶
你好，我是程远，好久不见。
距离我们的专栏更新结束，已经过去了不少时间。我仍然会在工作之余，到这门课的留言区转一转，回答同学的问题。大部分的疑问，我都通过留言做了回复。
除了紧跟更新的第一批同学，也很开心有更多新朋友加入到这个专栏的学习中。那课程的思考题呢，为了给你留足思考和研究的时间，我选择用加餐的方式，给你提供参考答案。
这里我想和你说明的是，我这里给你提供的参考答案，都是我能够直接给你特定答案的问题。至于操作类的题目，有的我引用了同学回复的答案。
另外一类操作题，是为了帮你巩固课程内容知识的，相信你可以从课程正文里找到答案。我还是建议你自己动手实战，这样你的收获会更大。
必学部分思考题¶
第 2 讲 Q：对于这一讲的最开始，有这样一个 C 语言的 init 进程，它没有注册任何信号的 handler。如果我们从 Host Namespace 向它发送 SIGTERM，会发生什么情况呢？
A：即使在宿主机上向容器 1 号进程发送 SIGTERM，在 1 号进程没有注册 handler 的情况下，这个进程也不能被杀死。
这个问题的原因是这样的：开始要看内核里的那段代码，“ !(force && sig_kernel_only(sig))”，
虽然由不同的 namespace 发送信号， 虽然 force 是 1 了，但是 sig_kernel_only(sig) 对于 SIGTERM 来说还是 0，这里是个 &&, 那么 !(1 && 0) = 1。
#define sig_kernel_only(sig) siginmask(sig, SIG_KERNEL_ONLY_MASK)
#define SIG_KERNEL_ONLY_MASK (\
rt_sigmask(SIGKILL) | rt_sigmask(SIGSTOP))
第 3 讲 Q：如果容器的 init 进程创建了子进程 B，B 又创建了自己的子进程 C。如果 C 运行完之后，退出成了僵尸进程，B 进程还在运行，而容器的 init 进程还在不断地调用 waitpid()，那 C 这个僵尸进程可以被回收吗？
A：这道题可以参考下面两位同学的回答。
Geek2014 用户的回答：
这时 C 是不会被回收的，只有等到 B 也被杀死，C 这个僵尸进程也会变成孤儿进程，被 init 进程收养，进而被 init 的 wait 机制清理掉。
莫名同学的回答：
C 应该不会被回收，waitpid 仅等待直接 children 的状态变化。
为什么先进入僵尸状态而不是直接消失？觉得是留给父进程一次机会，查看子进程的 PID、终止状态（退出码、终止原因，比如是信号终止还是正常退出等）、资源使用信息。如果子进程直接消失，那么父进程没有机会掌握子进程的具体终止情况。
一般情况下，程序逻辑可能会依据子进程的终止情况做出进一步处理：比如 Nginx Master 进程获知 Worker 进程异常退出，则重新拉起来一个 Worker 进程。第 4 讲
Q：请你回顾一下基本概念中最后的这段代码，你可以想一想，在不做编译运行的情况下，它的输出是什么？
# include \<stdio.h>
# include \<signal.h>
typedef void (\*sighandler_t)(int);
void sig_handler(int signo)
{
if (signo == SIGTERM) {
printf("received SIGTERM\n\n");
// Set SIGTERM handler to default
signal(SIGTERM, SIG_DFL);
}
//Ignore SIGTERM, and send SIGTERM
// to process itself.
signal(SIGTERM, SIG_IGN);
printf("Ignore SIGTERM\n\n");
kill(0, SIGTERM);
//Catch SIGERM, and send SIGTERM
// to process itself.
signal(SIGTERM, sig_handler);
printf("Catch SIGTERM\n");
kill(0, SIGTERM);
//Default SIGTERM. In sig_handler, it sets
//SIGTERM handler back to default one.
printf("Default SIGTERM\n");
kill(0, SIGTERM);
return 0;
A：可以参考用户 geek 2014 同学的答案。输出结果如下：
Ignore SIGTERM
Catch SIGTERM
received SIGTERM
Default SIGTERM
第 5 讲
Q：我们还是按照文档中定义的控制组目录层次结构图，然后按序执行这几个脚本：
create_groups.sh
update_group1.sh
update_group4.sh
update_group3.sh
那么，在一个 4 个 CPU 的节点上，group1/group3/group4 里的进程，分别会被分配到多少 CPU 呢?
A：分配比例是: 2 : 0.5 : 1.5
可以参考 geek 2014 的答案：
group1 的 shares 为 1024，quota 3.5，尝试使用 4，
group2 的 shares 默认为 1024，quota 设置为 -1，不受限制，也即是，如果 CPU 上只有 group2 的话，那么 group2 可以使用完所有的 CPU（实际上根据 group3 和 group4，group2 最多也就能用到 1.5+3.5 core）
故而，group1 和 group2 各分配到 2。把 group2 分到的 2CPU，看作总量，再次分析 group3 和 group4。group3 和 group3 尝试使用的总量超过 2，所以按照 shares 比例分配，group3 使用 1/(1+3) * 2 = 0.5，group4 使用 3/(1+3) * 2 = 1.5
第 6 讲 Q：写一个小程序，在容器中执行，它可以显示当前容器中所有进程总的 CPU 使用率。
A：上邪忘川的回答可以作为一个参考。
# !/bin/bash
cpuinfo1=(cat /sys/fs/cgroup/cpu,cpuacct/cpuacct.stat)
utime1=(echo cpuinfo1|awk '{print 2}')
stime1=(echo cpuinfo1|awk '{print 4}')
sleep 1
cpuinfo2=(cat /sys/fs/cgroup/cpu,cpuacct/cpuacct.stat)
utime2=(echo cpuinfo2|awk '{print 2}')
stime2=(echo cpuinfo2|awk '{print 4}')
cpus=((utime2+stime2-utime1-stime1))
echo "{cpus}%"
第 8 讲
Q：在我们的例子脚本基础上，你可以修改一下，在容器刚一启动，就在容器对应的 Memory Cgroup 中禁止 OOM，看看接下来会发生什么？
A：通过“memory.oom_control”禁止 OOM 后，在容器中的进程不会发生 OOM，但是也无法申请出超过“memory.limit_in_bytes”内存。
# cat start_container.sh
# !/bin/bash
docker stop mem_alloc;docker rm mem_alloc
docker run -d --name mem_alloc registry/mem_alloc:v1
sleep 2
CONTAINER_ID=$(sudo docker ps --format "{{.ID}}\\t{{.Names}}" | grep -i mem_alloc | awk '{print $1}')
echo $CONTAINER_ID
CGROUP_CONTAINER_PATH=$(find /sys/fs/cgroup/memory/ -name "*$CONTAINER_ID*")
echo $CGROUP_CONTAINER_PATH
echo 536870912 > $CGROUP_CONTAINER_PATH/memory.limit_in_bytes
echo 1 > $CGROUP_CONTAINER_PATH/memory.oom_control
cat $CGROUP_CONTAINER_PATH/memory.limit_in_bytes
第 10 讲 Q：在一个有 Swap 分区的节点上用 Docker 启动一个容器，对它的 Memory Cgroup 控制组设置一个内存上限 N，并且将 memory.swappiness 设置为 0。这时，如果在容器中启动一个不断读写文件的程序，同时这个程序再申请 ½N 的内存，请你判断一下，Swap 分区中会有数据写入吗？
A：Memory Cgroup 参数 memory.swappiness 起到局部控制的作用，因为已经设置了 memory.swappiness 参数，全局参数 swappiness 参数失效，那么容器里就不能使用 swap 了。第 11 讲 Q：在这一讲 OverlayFS 的例子的基础上，建立 2 个 lowerdir 的目录，并且在目录中建立相同文件名的文件，然后一起做一个 overlay mount，看看会发生什么？
A：这里引用上邪忘川同学的实验结果。
实验过程如下，结果是 lower1 目录中的文件覆盖了 lower2 中同名的文件, 第一个挂载的目录优先级比较高
\[\[\[email protected\] ~\]# cat overlay.sh
# !/bin/bash
umount ./merged
rm upper lower1 lower2 merged work -r
mkdir upper lower1 lower2 merged work
echo "I'm from lower1!" > lower1/in_lower.txt
echo "I'm from lower2!" > lower2/in_lower.txt
echo "I'm from upper!" > upper/in_upper.txt
# `in_both` is in both directories
echo "I'm from lower1!" > lower1/in_both.txt
echo "I'm from lower2!" > lower2/in_both.txt
echo "I'm from upper!" > upper/in_both.txt
sudo mount -t overlay overlay \\
-o lowerdir=./lower1:./lower2,upperdir=./upper,workdir=./work \\
./merged
\[\[email protected\] ~\]# sh overlay.sh
\[\[email protected\] ~\]# cat merged/in_lower.txt
I'm from lower1!
第 12 讲
Q：在正文知识详解的部分，我们使用"xfs_quota"给目录打了 project ID 并且限制了文件写入的数据量。那么在做完限制之后，我们是否能用 xfs_quota 命令，查询到被限制目录的 project ID 和限制的数据量呢？
A：xfs_quota 不能直接得到一个目录的 quota 大小的限制，只可以看到 project ID 上的 quota 限制，不过我们可以用这段程序来获得目录对应的 project ID。
# xfs_quota -x -c 'report -h /'
...
Project ID Used Soft Hard Warn/Grace
______________________________________________________________________
# 0 105.6G 0 0 00 \[------\]
# 101 0 0 10M 00 \[------\]
# ./get_proj /tmp/xfs_prjquota
Dir: /tmp/xfs_prjquota projectid is 101
第 13 讲 Q：这是一道操作题，通过这个操作你可以再理解一下 blkio Cgroup 与 Buffered I/O 的关系。
在 Cgroup V1 的环境里，我们在 blkio Cgroup V1 的例子基础上，把 fio 中“-direct=1”参数去除之后，再运行 fio，同时运行 iostat 查看实际写入磁盘的速率，确认 Cgroup V1 blkio 无法对 Buffered I/O 限速。
A: 这是通过 iostat 看到磁盘的写入速率，是可以突破 cgroup V1 blkio 中的限制值的。第 17 讲 Q：在这节课的最后，我提到“由于 ipvlan/macvlan 网络接口直接挂载在物理网络接口上，对于需要使用 iptables 规则的容器，比如 Kubernetes 里使用 service 的容器，就不能工作了”，请你思考一下这个判断背后的具体原因。
A：ipvlan/macvlan 工作在网络 2 层，而 iptables 工作在网络 3 层。所以用 ipvlan/macvlan 为容器提供网络接口，那么基于 iptables 的 service 服务就不工作了。第 18 讲
Q：在这一讲中，我们提到了 Linux 内核中的 tcp_force_fast_retransmit() 函数，那么你可以想想看，这个函数中的 tp->recording 和内核参数 /proc/sys/net/ipv4/tcp_reordering 是什么关系？它们对数据包的重传会带来什么影响？
struct tcp_sock *tp = tcp_sk(sk); return after(tcp_highest_sack_seq(tp),
tp->snd_una + tp->reordering * tp->mss_cache);
A: 在 TCP 链接建立的时候，tp->reordering 默认值是从 /proc/sys/net/ipv4/tcp_reordering（默认值为 3）获取的。之后根据网络的乱序情况，进行动态调整，最大可以增长到 /proc/sys/net/ipv4/tcp_max_reordering (默认值为 300) 的大小。
第 20 讲 Q：我在这一讲里提到了 rootless container，不过对于 rootless container 的支持，还存在着不少的难点，比如容器网络的配置、Cgroup 的配置，你可以去查阅一些资料，看看 podman 是怎么解决这些问题的。
A：可以阅读一下这篇文档。
专题加餐 ---- 专题 03 Q：我们讲 ftrace 实现机制时，说过内核中的“inline 函数”不能被 ftrace 到，你知道这是为什么吗？那么内核中的“static 函数”可以被 ftrace 追踪到吗？
A：inline 函数在编译的时候被展开了，所以不能被 ftrace 到。而 static 函数需要看情况，如果加了编译优化参数“-finline-functions-called-once”，对于只被调用到一次的 static 函数也会当成 inline 函数处理，那么也不能被 ftrace 追踪到了。专题 04
Q：想想看，当我们用 kprobe 为一个内核函数注册了 probe 之后，怎样能看到对应内核函数的第一条指令被替换了呢？
A：首先可以参考莫名同学的答案：
关于思考题，想到一个比较笨拙的方法：gdb+qemu 调试内核。先进入虚拟机在某个内核函数上注册一个 kprobe，然后 gdb 远程调试内核，查看该内核函数的汇编指令（disass）是否被替换。应该有更简单的方法，这方面了解不深。
另外，我们用 gdb 远程调试内核看也可以。还可以通过 /proc/kallsyms 找到函数的地址，然后写个 kernel module 把从这个地址开始后面的几个字节 dump 出来，比较一下 probe 函数注册前后的值。 ```