内核更新后重新引导Linux重要吗？

我有一些生产Fedora和Debian Web服务器，它们托管着我们的网站以及用户外壳程序帐户（用于git vcs工作，一些screen + irssi会话等）。

有时会在yum/ 的管道中进行新的内核更新apt-get，我想知道大多数修补程序是否严重到足以保证可以重新引导，或者我是否可以在不重新引导的情况下应用这些修补程序。

我们的主要开发服务器目前有213天的正常运行时间，我不确定运行这样一个较旧的内核是否不安全。

长时间正常运行并没有什么特别的。通常最好有一个安全的系统。所有系统有时都需要更新。您可能已经在应用更新，应用这些更新时是否计划中断？您可能应该以防万一出问题了。重启实际上不需要那么多时间。

如果您的系统对中断非常敏感，则您可能应该考虑某种集群设置，以便在不降低所有性能的情况下更新集群的单个成员。

如果不确定某个特定更新，安排重新启动并应用它可能更安全（最好是在另一个类似的系统上进行测试之后）。

如果您有兴趣了解更新是否重要，请花一些时间阅读安全声明，并按照链接返回至CVE或描述问题的帖子/列表/博客。这应该可以帮助您确定更新是否直接适用于您的情况。

即使您认为它不适用，也应最终考虑更新系统。安全性是一种分层的方法。您应该假设其他时间可能会失败。另外，您可能会忘记您的系统很脆弱，因为在以后的某个时间更改配置时跳过了更新。

无论如何，如果您想忽略或在基于Debian的系统上等待一段时间以进行更新，可以将软件包置于保留状态。我个人希望保留所有内核软件包，以防万一。

CLI方法，用于在基于Debian的系统上设置对软件包的保留。

dpkg --get-selections | grep 'linux-image' | sed -e 's/install/hold/' | sudo dpkg --set-selections

大多数更新不需要重新启动，但是内核更新需要重新启动（如果不重新启动，则无法真正替换正在运行的内核）。

我发现的一件事是，如果您的服务器已经长时间运行而没有重新引导，则在重新引导时更有可能希望执行磁盘检查（fsck），这会大大增加恢复时间重新运行。最好预见并计划。

我还发现，有时可能会丢失配置更改，并且直到重新启动后才会注意到配置更改（例如添加新的IP地址/ iptables规则等），这也增加了不频繁重新启动时的“停机风险”。

最好在重新启动时计划一些停机时间-如果这不是理想的选择，请在群集中设置服务器，以便在必要时可以重新启动。

如果您只需要安全更新而不是一个全新的内核，则可能对Ksplice感兴趣-它使您可以将某些内核更新修补到正在运行的内核中。

这没有简单的答案，有些内核升级与安全性没有真正关系，有些可能会解决不影响您的安全性问题，而另一些可能会影响您。

imo的最佳方法是注册相关的安全邮件列表，例如ubuntu的安全公告，以便您可以看到何时发布安全补丁，以及它们如何影响您。

我还将考虑使用apticron或类似的工具来获取任何其他软件包更新的详细信息和变更日志。

这是更新的功能-如果它修复了priv。升级导致根访问，那么您可能要应用它。

如果您不重新引导，则应确保新内核不是引导时启动的默认内核。

您需要做的最后一件事是在计划外重启后将未经测试的内核用于生产。

如mibus所述，如果您安装内核并且不重新引导，请确保它不是默认内核。您不知道服务器是否或以何种状态恢复正常，因此请确保已对其进行测试。

话虽这么说，我认为最好在可能的情况下养成定期重启机器的习惯。许多硬件和软件故障只会在重新启动时才会显现出来，最好是在计划重新启动时查找这些故障，而不是在计划外停机期间进行查找。

请注意，某些debian内核更新要求（很好，强烈建议）在应用它们后尽快重新启动。

当差异不足以保证模块目录更改但模块可能有所不同时，就是这种情况。

安装此类内核软件包时，Debian将警告您。