☰

如何证明“rebo​​ot -f”命令被阻塞？

tag-icon • tag-icon linux shell
如何证明“rebo​​ot -f”命令被阻塞？

在为嵌入式 Linux 设备编写 shell 脚本时，我的大学倾向于在reboot/reboot -f命令后添加无限循环，以确保脚本的后面部分在重新启动期间不会运行。但是我想知道这是否reboot -f实际上是一个阻塞命令。

我试过了reboot; touch test，并且test创建了。因此，正常reboot应该是非阻塞的。但是，运行reboot -f ; touch test命令不会创建test。有些人可能会争辩说，touch或者 shell 可能在 touch` 执行之前就被杀死了，所以这不是充分的证据。

实际上是rebootsysvinit 可执行文件的符号链接halt。

有人可以给出证明或解释吗？谢谢。

答案1

根据您的操作系统，reboot可能会有很大不同。对我来说，reboot是 systemctl 的符号链接：

ls -la /sbin/reboot
lrwxrwxrwx 1 root root 14 maj  3 13:30 /sbin/reboot -> /bin/systemctl

在这种情况下，它相当于systemctl rebootwhich相当于systemctl start reboot.target --job-mode=replace-irreversibly --no-block（参见systemctl的手册页）。

-force在这种情况下，只会加速重新启动的过程，可能会导致 shell 在文件被触及之前被终止。
如果你想阻止它，你可以尝试类似的方法systemctl start reboot.target --job-mode=replace-irreversibly。但我不确定是否可以像这样实现阻塞重启。

不过，如果您处于非 systemd 环境中，reboot则工作方式可能会有所不同。

我认为，无限循环不是这里最干净的解决方案，您可以exit在重新启动后执行。

相关内容