宽限期后的 SIGKILLing

Question

我见过很多流程经理试图这样做。我的理解是您应该只使用 SIGTERM 来终止进程。该过程可能需要未知的时间来自行清理；在缓慢的系统上，可能需要几分钟。我一直认为唯一的解决办法就是耐心等待程序清理干净并优雅退出。如果该进程没有捕获 SIGTERM，那么这是一个错误，应该报告给软件的维护者。

我已经看到像 docker 这样的流行工具也试图这样做：

用法：docker stop [OPTIONS] CONTAINER [CONTAINER...]

停止正在运行的容器（发送 SIGTERM，然后在宽限期后发送 SIGKILL）

这是不好的做法吗？我还好奇的一件事是关闭过程如何在 SystemV 风格的初始化系统上工作。我查看了一些联机帮助页和其他一些问题，但找不到明确的答案。我猜每个 init 服务（术语？）都会看到运行级别的变化并执行 init 脚本中定义的正确“停止”函数。它是否逐一执行此操作，以确保每项服务都正确结束？未由 init 脚本处理的进程会发生什么？我已经看到一些问题模糊地提到了在 SIGKILL 之前使用的宽限期，但我希望有人能详细说明或至少指出我正确的方向。:)

如果有人可以帮助我了解更多有关 systemd 如何工作的信息，我很乐意研究并了解更多信息。我看过手册页，但在这里也找不到任何明确的内容。

Answer 1

你可以吃蛋糕，也可以吃蛋糕。只要它需要（或想要）对 SIGTERM 做出反应，程序就希望拥有它。系统（程序管理器）希望能够终止。如果系统永远等待，这允许程序通过从不响应（因为程序是恶意的或因为它有缺陷）来劫持系统关闭。

在正常的关闭序列中，每个守护程序都通过守护程序的作者或打包程序提供的初始化脚本（如果您愿意，可以将其称为关闭脚本）终止。根据守护进程的不同，init 脚本可能只是向它发送一个信号，或者它可能会执行更可控的关闭（例如，通过写入套接字）。init 脚本可能会等待守护进程报告它已令人满意地关闭，或者它可能会强行杀死它。初始化脚本以 root 身份运行（他们可能会调用su以以较低权限的用户身份执行部分任务）；他们应该是合作的，所以他们可以让系统永远挂起。

一旦 init 脚本完成它们的工作，所有服务都应该关闭。任何剩余的过程都应该是不重要的或行为不端的。所以在这个阶段，剩余的进程被告知关闭（SIGTERM），在一个宽限期（给他们最后一次彻底关闭的机会）之后，系统必须关闭，以便强行杀死所有剩余的进程（SIGKILL）。

将 init 脚本视为正常的逮捕程序——出示逮捕令、发出警告等。守法守护进程此时应该关闭，尽管守护进程有律师（init 脚本）可以延迟程序，只要他们想。一旦正常进程完成，剩余的守护进程就被认为是敌对的。系统发出警告信号 (SIGTERM)，然后在延迟后发出 SIGKILL 信号。