13 KiB
加餐福利 | 课后思考题答案合集
你好，我是程远，好久不见。
距离我们的专栏更新结束，已经过去了不少时间。我仍然会在工作之余，到这门课的留言区转一转，回答同学的问题。大部分的疑问，我都通过留言做了回复。
除了紧跟更新的第一批同学，也很开心有更多新朋友加入到这个专栏的学习中。那课程的思考题呢，为了给你留足思考和研究的时间，我选择用加餐的方式，给你提供参考答案。
这里我想和你说明的是，我这里给你提供的参考答案，都是我能够直接给你特定答案的问题。至于操作类的题目，有的我引用了同学回复的答案。
另外一类操作题，是为了帮你巩固课程内容知识的，相信你可以从课程正文里找到答案。我还是建议你自己动手实战，这样你的收获会更大。
必学部分思考题
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))
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进程。
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);
}
}
int main(int argc, char *argv[])
{
//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
Q：我们还是按照文档中定义的控制组目录层次结构图，然后按序执行这几个脚本：
那么，在一个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
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}%"
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
Q：在一个有Swap分区的节点上用Docker启动一个容器，对它的Memory Cgroup控制组设置一个内存上限N，并且将memory.swappiness设置为0。这时，如果在容器中启动一个不断读写文件的程序，同时这个程序再申请1/2N的内存，请你判断一下，Swap分区中会有数据写入吗？
A：Memory Cgroup参数memory.swappiness起到局部控制的作用，因为已经设置了memory.swappiness参数，全局参数swappiness参数失效，那么容器里就不能使用swap了。
Q：在这一讲OverlayFS的例子的基础上，建立2个lowerdir的目录，并且在目录中建立相同文件名的文件，然后一起做一个overlay mount，看看会发生什么？
A：这里引用上邪忘川同学的实验结果。
实验过程如下，结果是lower1目录中的文件覆盖了lower2中同名的文件, 第一个挂载的目录优先级比较高
[[root@localhost ~]# 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
[root@localhost ~]# sh overlay.sh
[root@localhost ~]# cat merged/in_lower.txt
I'm from lower1!
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
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中的限制值的。
Q：在这节课的最后，我提到“由于ipvlan/macvlan网络接口直接挂载在物理网络接口上，对于需要使用iptables规则的容器，比如Kubernetes里使用service的容器，就不能工作了”，请你思考一下这个判断背后的具体原因。
A：ipvlan/macvlan工作在网络2层，而iptables工作在网络3层。所以用ipvlan/macvlan为容器提供网络接口，那么基于iptables的service服务就不工作了。
Q：在这一讲中，我们提到了Linux内核中的tcp_force_fast_retransmit()函数，那么你可以想想看，这个函数中的tp->recording和内核参数 /proc/sys/net/ipv4/tcp_reordering是什么关系？它们对数据包的重传会带来什么影响？
static bool tcp_force_fast_retransmit(struct sock *sk)
{
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)的大小。
Q：我在这一讲里提到了rootless container，不过对于rootless container的支持，还存在着不少的难点，比如容器网络的配置、Cgroup的配置，你可以去查阅一些资料，看看podman是怎么解决这些问题的。
A：可以阅读一下这篇文档。
专题加餐
Q：我们讲ftrace实现机制时，说过内核中的“inline函数”不能被ftrace到，你知道这是为什么吗？那么内核中的“static函数”可以被ftrace追踪到吗？
A：inline函数在编译的时候被展开了，所以不能被ftrace到。而static函数需要看情况，如果加了编译优化参数“-finline-functions-called-once”，对于只被调用到一次的static函数也会当成inline函数处理，那么也不能被ftrace追踪到了。
Q：想想看，当我们用kprobe为一个内核函数注册了probe之后，怎样能看到对应内核函数的第一条指令被替换了呢？
A：首先可以参考莫名同学的答案：
关于思考题，想到一个比较笨拙的方法：gdb+qemu调试内核。先进入虚拟机在某个内核函数上注册一个kprobe，然后gdb远程调试内核，查看该内核函数的汇编指令（disass）是否被替换。应该有更简单的方法，这方面了解不深。
另外，我们用gdb远程调试内核看也可以。还可以通过 /proc/kallsyms找到函数的地址，然后写个kernel module把从这个地址开始后面的几个字节dump出来，比较一下probe函数注册前后的值。