为什么在Debian Linux上，“ shutdown -r now”的行为与“ reboot -f”不同？

我最近不得不处理一个讨厌的，间歇性的NFS客户端/服务器挂载点问题。当客户端发生问题时，我将无法卸载，以及其他一些奇怪的行为。到目前为止，我唯一需要立即解决的问题是重新启动客户端盒。

但是shutdown -r now根本不起作用。从那以后reboot -f，我发现了，它确实重新启动了系统。为什么？我已经阅读了手册页，但似乎没有任何问题可以回答我的问题。

为什么shutdown -r now行为不同于reboot -f？

（我正在继续解决NFS问题，但这不是我的问题。）

从关闭手册页：

一旦TIME过去，shutdown将向init（8）守护程序发送一个请求，以使系统进入适当的运行级别。

init随着系统更改运行级别来启动和停止作业。由于重新引导进入运行级别6时，系统将运行/etc/rc6.d中的所有脚本。由于您的系统没有响应shutdown，很可能是其中的一个脚本/etc/rc6.d（可能是K05nfs-common由于您的NFS问题）卡住了，不允许关闭序列完成。实际上，更改为运行级别6时，运行init的最后一件事是reboot -d -f -i。

reboot -f 跳过所有脚本并直接重新引导系统。

shutdown指示init开始关闭过程，该过程包括让登录的用户知道系统正在关闭，优雅地杀死所有进程，卸载和同步驱动器，等等。您之所以会挂在这里，是因为等待IO阻塞的进程往往很难杀死，并且无法卸载NFS挂载。

reboot -f另一方面，无需任何操作即可立即重新引导服务器。（reboot是程序init调用以关闭服务器。如果没有该-f标志，它将检查是否init认为它当前正在重新引导，否则，它将调用shutdown以启动该过程）。

因为'reboot -f'不会进入运行级别0，所以它告诉OS直接重新初始化CPU。我最近的Linux机器上的手册页显示：

 -f     Force halt or reboot, don't call shutdown(8)

关机手册页介绍了更多信息。

如果intr在NFS挂载上使用该选项，则shutdown -r now应该能够杀死等待NFS IO完成的进程。这可能会导致文件损坏，但可能只不过是shutdown -f创建文件而已。