use*_*126 13 ubuntu update upgrade linux-kernel
Ubuntu 的软件更新经常需要重新启动（这可能会产生副作用，例如停机时间）。
我看到 Ubuntu 有https://www.ubuntu.com/livepatch，它允许在不重启的情况下进行内核更新，但是，这是一项付费服务。还有ksplice。
是否存在升级/补丁不需要重启的 Linux 发行版/进程？
（我知道设置高可用性 (HA) 服务器并拥有一次性服务器是最佳实践 - 所以我不是在要求保持服务，而是在实际服务器上。）
kas*_*erd 30
使服务高度可用和使单个机器高度可用之间存在重要区别。
在大多数情况下，目标是使服务高度可用，而单个机器的可用性只是实现该目标的一种手段。但是，通过提高单个机器的可用性，您可以在多大程度上实现目标。
即使您可以消除由于需要更新软件而导致的所有停机时间，但单个机器仍然不能 100% 可用。因此，为了将服务的可用性提高到高于单个机器的可用性，您必须在更高级别设计冗余。你问题的最后一句话表明，至少原则上你知道这一点。
如果您设计的服务比单个机器提供的可用性更高，那么实现单个机器的高可用性就不再有压力。因此，对于高可用服务，无需避免重新启动。相反，您可以牺牲个别机器的某些可靠性来节省成本，这些成本可以用于其他领域，您可以获得更高的可靠性收益。
一旦高级系统被设计为在单个硬件组件失败的情况下是可靠的，内核的实时补丁就会从优势变为风险。
这是一种风险，因为实时修补的机器与使用最新内核版本启动的机器之间的行为可能存在细微差别。这可能会引入一个潜在的错误，该错误可能会在下次重新启动机器时导致中断。这种风险会因重新启动而被放大，从而被视为缓解某些中断的一种方法。
有一天，您可能会遇到中断，您认为重新启动机器可能会有所帮助。但是当您重新启动时，您会遇到阻止机器恢复到所需状态的潜在错误。实时修补并不是这种潜在错误发生的唯一方式，它也可能是由于手动启用服务但从未配置为在启动期间启动，或者配置为过早启动而导致的一些普通事情发生由于不满意的依赖关系而无法出现。
由于这些原因，通过以足够慢的速度定期重启单个机器，您可以检测问题并在问题发生时暂停重启序列，实际上可能更容易实现高可用性服务。
Pau*_*ear 12
对于您的问题，“是否有升级/补丁不需要重启的 Linux 发行版/进程？”，我不知道有任何，而且我非常怀疑是否会有任何真正免重启的发行版/进程。除了迈克尔汉普顿关于为什么实时修补在任何地方都不是开箱即用的体验的评论之外，实时修补也无法达到与重新启动相同的结果。
说明这一点的轶事：我最近调查了一个问题，其中一个特定实用程序开始在大量机器上进行段错误。我试着查看它曾经使用过的共享库，看看最近升级的东西是否破坏了它；ldd 说它不是一个可执行文件（即使当我将相同的二进制文件拉到我的笔记本电脑上时，ldd 可以很好地看到共享库依赖项）。我尝试在 gdb 中逐步完成；它甚至在到达第一条指令之前就发生了段错误。
查看故障发生的时间，我发现最近应用了一个Ksplice补丁。我退出了补丁，二进制文件没有段错误，然后重新添加它，它再次开始段错误。重新启动到同等修补的内核工作正常。结果证明这是一个支持 32 位的补丁，Ksplice 的人并没有完全正确地应用它。值得称赞的是，他们在几个小时内发布了一个固定补丁，并且无需干预即可在我们的舰队上正常工作。
另一个例子：Meltdown/Spectre 补丁是如此具有侵入性，以至于 Ubuntu 内核团队认为实时补丁是不切实际的，并要求人们在再次接收实时补丁之前将他们的系统重新启动到固定内核。
我们在工作中运行大量物理和虚拟服务器，以及大量 Ksplice 和 Canonical Livepatch 系统。它们都比许多其他软件可靠得多，但我仍然更愿意看到我们的服务采用易于重启的架构设计，而不是依赖内核实时修补。