如何解决如果运行它的可执行文件被删除，为什么 fork() 在 MacOs Big Sur 上会失败？ 修改示例以更好地说明问题追踪失败的例子更奇怪的例子问题的根本原因结论
如果正在运行的进程的可执行文件被删除，我注意到 fork 失败，子进程从未执行过。
例如，考虑下面的代码：
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/wait.h>
int main(void) {
sleep(5);
pid_t forkResult;
forkResult = fork();
printf("after fork %d \n",forkResult);
return 0;
}
如果我在调用 fork 之前编译它并删除生成的可执行文件，我永远不会看到 fork 返回 0 的 pid，这意味着子进程永远不会启动。我只有一台运行 Big Sur 的 Mac，所以不确定这是否在其他操作系统上重现。
有谁知道为什么会这样？我的理解是一个可执行文件应该可以正常工作，即使它在仍在运行时被删除。
解决方法
即使二进制文件被删除，进程仍应继续的预期是正确的，但在 macOS 的情况下并不完全正确。这个例子是 macOS 内核中的 System Integrity Protection (SIP) 机制的副作用，但是在解释到底发生了什么之前，我们需要做几个实验，这将有助于我们更好地了解整个场景。
修改示例以更好地说明问题
为了演示发生了什么，我将示例修改为数到 9，而不是分叉，分叉后，孩子将打印一条消息“我完成了”，等待 1 秒并通过打印 { 退出{1}} 作为 PID。父进程将继续数到 14 并打印子进程的 PID。代码如下：
0编译后，我开始了正常的场景：
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/wait.h>
int main(void) {
for(int i=0; i <10; i++)
{
sleep(1);
printf("%i ",i);
}
pid_t forkResult;
forkResult = fork();
if (forkResult != 0) {
for(int i=10; i < 15; i++) {
sleep(1);
printf("%i ",i);
}
} else {
sleep(1);
printf("I am done ");
}
printf("after fork %d \n",forkResult);
return 0;
}
因此，正常情况按预期工作。我们两次看到从 0 到 9 的计数，这是由于 ╰> ./a.out
0 1 2 3 4 5 6 7 8 9 I am done after fork 0
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 after fork 4385
的缓冲区副本在 fork 调用中完成的。
追踪失败的例子
现在是时候做负面的场景了，我们将在启动后等待 5 秒并删除二进制文件。
stdout我们看到输出仅来自父级。由于父母已经数到 14，并且显示了孩子的有效 PID，但是孩子丢失了，它从未打印任何内容。因此，在执行 ╰> ./a.out & (sleep 5 && rm a.out)
[4] 8555
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 after fork 8677
[4] 8555 done ./a.out
后子创建失败，否则 fork() 将收到错误而不是有效的 fork()。来自 PID 的跟踪显示该子进程是在 pid 下创建并被唤醒的：
ktrace因此子进程使用 test5-ko.txt:2021-04-07 13:34:26.623783 +04 0.3 MACH_DISPATCH 1bc 0 84 4 888065 2 a.out(8677)
test5-ko.txt:2021-04-07 13:34:26.623783 +04 0.2 TMR_TimerCallEnter 9931ba49ead1bd17 0 330e7e4e9a59 41 888065 2 a.out(8677)
test5-ko.txt:2021-04-07 13:34:26.623783 +04 0.0(0.0) TMR_TimerCallEnter 9931ba49ead1bd17 0 330e7e4e9a59 0 888065 2 a.out(8677)
test5-ko.txt:2021-04-07 13:34:26.623783 +04 0.0 TMR_TimerCallEnter 9931ba49ead1bd17 0 330e7e4e9a59 0 888065 2 a.out(8677)
test5-ko.txt:2021-04-07 13:34:26.623854 +04 0.0 imp_thread_qos_and_relprio 88775d 20000 20200 6 888065 2 a.out(8677)
test5-ko.txt:2021-04-07 13:34:26.623854 +04 0.0 imp_update_thread 88775d 811200 140000100 1f 888065 2 a.out(8677)
test5-ko.txt:2021-04-07 13:34:26.623855 +04 0.1(0.8) imp_update_thread 88775d c15200 140000100 25 888065 2 a.out(8677)
test5-ko.txt:2021-04-07 13:34:26.623855 +04 0.0(1.1) imp_thread_qos_and_relprio 88775d 30000 20200 40 888065 2 a.out(8677)
test5-ko.txt:2021-04-07 13:34:26.623855 +04 0.0 imp_thread_qos_workq_override 88775d 30000 20200 0 888065 2 a.out(8677)
test5-ko.txt:2021-04-07 13:34:26.623855 +04 0.0 imp_update_thread 88775d c15200 140000100 25 888065 2 a.out(8677)
test5-ko.txt:2021-04-07 13:34:26.623855 +04 0.1(0.1) imp_update_thread 88775d c15200 140000100 25 888065 2 a.out(8677)
test5-ko.txt:2021-04-07 13:34:26.623855 +04 0.0(0.2) imp_thread_qos_workq_override 88775d 30000 20200 40 888065 2 a.out(8677)
test5-ko.txt:2021-04-07 13:34:26.623857 +04 1.3 TURNSTILE_turnstile_added_to_thread_heap 88775d 9931ba6049ddcc77 0 0 888065 2 a.out(8677)
test5-ko.txt:2021-04-07 13:34:26.623858 +04 1.0 MACH_MKRUNNABLE 88775d 25 0 5 888065 2 a.out(8677)
t
分派，并使用 MACH_DISPATCH 使其可运行。这就是父级在 MACH_MKRUNNABLE 之后获得有效 PID 的原因。
此外，正常情况下的 fork() 表明进程发出了 ktrace 并且发生了 BSC_exit 系统调用，这是进程退出的正常方式。但是，在我们删除文件的第二种情况下，跟踪没有显示 imp_task_terminated。这意味着子进程被内核终止，而不是正常终止。我们知道终止发生在正确创建子进程之后，因为父进程收到了有效的 PID 并且 PID 变为可运行的。
这让我们更接近于理解这里发生的事情。但是，在得出结论之前，让我们展示另一个更“扭曲”的例子。
更奇怪的例子
如果我们在启动进程后替换文件系统上的二进制文件会怎样？
这是回答这个问题的测试：我们将启动进程，删除二进制文件，并在他的位置用 BSC_exit 创建一个同名的空文件。
touch等一下，这行得通！？这是怎么回事！？！？
这个奇怪的例子给了我们重要的线索，可以帮助我们解释发生了什么。
问题的根本原因
第三个示例有效而第二个示例失败的原因揭示了这里发生的很多事情。正如开头提到的，我们遇到了 ╰> ./a.out & (sleep 5 && rm a.out; touch a.out)
[1] 6264
0 1 2 3 4 5 6 7 8 9 I am done after fork 0
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 after fork 6851
[1] + 6722 done ./a.out
的副作用，更准确地说是 SIP 机制。
为了保护系统完整性，runtime protection 将检查 SIP 和 system protection 的运行进程。来自苹果文档：...当一个进程启动时，内核会检查主可执行文件是否在磁盘上受到保护或是否使用特殊的系统授权进行签名。如果任一为真，则设置一个标志以表示它受到保护以防止修改。内核拒绝任何附加到受保护进程的尝试...
当我们从文件系统中删除二进制文件时，保护机制无法识别子进程的类型，也无法识别特殊系统权限，因为磁盘中缺少二进制文件。这触发了保护机制，将此进程视为系统中的入侵者并终止它，但我们还没有看到子进程的 special entitlement。
在第三个示例中，当我们使用 BSC_exit 在文件系统上创建虚拟条目时，touch 能够检测到这不是特殊进程也没有特殊权限并允许该进程接着说。这是一个非常可靠的迹象，表明我们在 SIP 实时保护机制上绊倒了。
为了证明是这样，我禁用了需要在恢复模式下重启的 SIP 并执行了测试
SIP结论
因此，整个问题都是由 ╰> csrutil status
System Integrity Protection status: disabled.
╰> ./a.out & (sleep 5 && rm a.out)
[1] 1504
0 1 2 3 4 5 6 7 8 9 I am done after fork 0
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 after fork 1626
引起的。更多细节可以在documentation
所需的所有 System Integrity Protection 就是在文件系统上有一个带有进程名称的文件，因此该机制可以运行验证并决定允许子进程继续执行。这表明我们观察到的是副作用，而不是设计的行为，因为空文件甚至不是有效的 SIP，但执行仍在继续。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
