don’t use kill-9 unless absolutely
necessary! SIGKILL can’t be trapped so
the killed program can’t run any
shutdown routines to e.g.erase
temporary files. First try HUP(1),
then INT(2),then QUIT(3)
我原则上同意SIGKILL，但剩下的是对我的消息。假设kill发送的默认信号是SIGTERM，我会期望它是用于正常关闭任意进程的最常见的预期信号。此外，我看到SIGHUP用于非终止的原因，如告诉守护进程“重新读取您的配置文件”。在我看来，SIGINT(你通常用Ctrl-C得到的同样的中断，对吗？)没有得到广泛支持，或者不合适地终止。
鉴于SIGKILL是最后的手段 – 哪些信号，以什么顺序，你应该发送到一个任意的过程，以尽可能优雅地关闭它？
请证明您的答案与支持事实(超出个人偏好或意见)或参考，如果可以。
注意：我特别感兴趣的最佳实践，包括bash / Cygwin的考虑。
编辑：到目前为止，没有人提到INT或QUIT，并且对HUP的提及有限。有任何理由将这些包括在有序的过程杀戮中吗？
有些人认为终止进程的智能标准方法是通过发送一系列信号，如HUP，INT，TERM和最后KILL。这是荒唐的。正确的终止信号是SIGTERM，如果SIGTERM不立即终止进程，你可能更喜欢，这是因为应用程序已经选择处理信号。这意味着它有一个非常好的理由不立即终止：它有清理工作要做。如果你中断清理工作与其他信号，没有告诉什么数据从内存，它还没有保存到磁盘，什么客户端应用程序被挂起，或者你是否中断它“中期”，这是有效的数据损坏。
有关信号的真正含义的更多信息，请参阅sigaction(2)。不要将“默认操作”与“说明”混淆，他们不是同一件事。
SIGINT用于表示过程的交互式“键盘中断”。一些程序可以以特殊方式为终端用户的目的处理这种情况。
SIGHUP用于表示终端已经消失，并且不再查看进程。就这些。一些进程选择关闭响应，一般是因为他们的操作没有意义没有终端，一些选择做其他事情，如重新检查配置文件。
SIGKILL用于强制从内核中删除该进程。这是特别的，它不是一个实际上是一个信号的过程，而是直接由内核解释。
不要发送SIGKILL。 SIGKILL肯定不会被脚本发送。如果应用程序处理SIGTERM，它可以花一秒钟来清理，它可能需要一分钟，它可能需要一个小时。根据应用程序必须完成之前，它准备结束。任何“假定”应用程序清理序列的逻辑已经花费了足够长的时间，并且需要在X秒后出现快捷方式或SIGKILL。
应用程序需要SIGKILL来终止的唯一原因是，如果在清理序列期间出现了错误。在这种情况下，您可以手动打开终端和SIGKILL。除此之外，唯一的另一个原因，为什么你SIGKILL的东西是因为你想防止它清理自己。
这不是因为一半的世界使用SIGKILL 5秒后，这不是可怕的错。
