成像 我正在运行邮件服务器，例如 exim4（或数据库、系统日志守护程序...）。现在，在更新此软件包时，我假设应用程序必须停止或至少在更新后重新启动。如果在这段时间内发送电子邮件，就会失败。更新时是否考虑到这种情况，有没有采取对策，或者是由发送邮件的软件稍后再次发送邮件？
答案1
通常，由软件发送电子邮件将其排队，直到服务可用。当服务器不可访问时，有多种可能的原因，这意味着发送即连接到服务器的软件必须具有重新连接和重试事务的机制。
除此之外，我还得问一下，如果您知道无法停机，为什么还要升级系统上的任何软件？您正在下载（？）、解包（？）并替换该特定软件的可执行文件和可能的共享库，这可能会失败，导致您的系统无法使用，所以如果您不能停机，为什么要这样做？
答案2
它完全取决于软件的功能以及软件包的安装/更新脚本。
有些程序将在升级期间继续正常工作，并且只需要在升级完成后重新启动......并且通常，包维护者通过他们的打包脚本利用这一事实。
（当我看到某个软件包在升级过程中不必要地停止时，我通常会将其报告为错误，因为这可能会导致极长的中断，例如，apt-get dist-upgrade如果有许多软件包需要升级，或者正在升级的软件包之一提出了一个问题我还倾向于单独升级最重要的服务，而不是作为分布式升级的一部分，以最大限度地减少停机时间......当然，是在非生产机器上测试升级之后）
其他程序在运行时并不能容忍环境的变化，需要在升级过程中停止。同样，这通常由包维护者的脚本自动处理。
在这两种情况下，软件包维护者的工作就是充分了解他们正在打包的软件，以便采取最适当的操作。
答案3
大多数 MTA 的操作方式是将电子邮件放入队列目录中，然后拾取排队的文件并在可能的情况下发送它们。在 MTA 升级期间，发送电子邮件的守护程序将停止一小段时间，但如果客户端程序发送电子邮件，则当守护程序重新启动时，该电子邮件仍将排队等待处理。
另一方面，如果另一台服务器尝试联系此服务器但由于正在进行升级而没有得到答复，则另一台服务器会将电子邮件排队并在短时间间隔后重试。电子邮件传送被设计为高度可靠（尽管它不如以前那么可靠，这在很大程度上是由于垃圾邮件和垃圾邮件对策的影响）。
对于其他类型的软件，守护进程重新启动时可能会出现短暂的停机时间。这种停机时间通常是通过拥有多个服务器计算机并平衡它们之间的连接来处理的。无论如何，这种冗余对于高可用性系统来说是必要的（硬件故障总是可能发生）。
答案4
有可以在不停机的情况下更新的软件。因此，该软件必须能够同时运行两个版本——新版本和旧版本。在更新期间，旧版本仍然为连接到它的客户端提供服务。更新后，新版本接管控制权并处理新客户端。旧版本会在最后一个客户端断开连接后关闭，然后可以删除（或者如果新版本无法正常工作，则保留在后台作为回退模式，并且实现了优雅降级的机制。）但是这些机制已实现在极少数用例中。
否则乔丹关于裁员的评论是正确的。