イメージャは、exim4（またはデータベース、syslogデーモン...）などのメールサーバーを実行しています。これで、このパッケージを更新するときに、更新後にアプリケーションを停止するか、少なくとも再起動する必要があるとします。この時間内にメールを送信すると失敗します。アップデート時にこのような状況を考慮するのか、どんな対策があるのでしょうか、それとも電子メールを後で再送するソフトウェアですか？
答え1
通常、電子メールはサービスが提供されるまでキューに入れたソフトウェアを介して送信されます。サーバーに接続できない場合は、いくつかの理由が考えられます。つまり、サーバーに接続するソフトウェア転送には、トランザクションを再接続して再試行するメカニズムが必要です。
それ以外にダウンタイムがないことがわかっている場合は、システムのソフトウェアをアップグレードする理由が何であるかを尋ねたいと思います。特定のソフトウェアの実行可能ファイルと共有ライブラリをダウンロード（？）し、解凍して（？）交換していますが、これが失敗してシステムが利用できなくなる可能性があります。
答え2
これはすべてソフトウェアの機能とパッケージのインストール/更新スクリプトによって異なります。
一部のプログラムはアップグレード中も正常に動作し続け、アップグレードが完了した後に再起動するだけです。そしてしばしば、パッケージマネージャはパッケージングスクリプトを通してこの事実を利用します。
（アップグレード中にパッケージが不要に停止した場合、通常はバグとして報告します。たとえば、apt-get dist-upgradeアップグレードする必要があるパッケージが多い場合、またはパッケージの1つをアップグレードするときにエラーが発生した場合、非常に長い中断が発生する可能性があるため）。問題は、ダウンタイムを最小限に抑えるために、分散アップグレードの一部ではなく最も重要なサービスを個別にアップグレードすることを好みます。
他のプログラムは実行中の環境の変更を許可できないため、アップグレードプロセス中に停止する必要があります。繰り返しますが、これは通常、パッケージマネージャのスクリプトによって自動的に処理されます。
どちらの場合も、最も適切な対策を講じるためにパッケージ化するソフトウェアを完全に理解することは、パッケージマネージャの使命です。
答え3
ほとんどのMTAの仕組みは、電子メールメッセージをキューディレクトリに配置し、キュー内のファイルを選択して可能な場合に送信することです。 MTAのアップグレード中に電子メールを送信するデーモンはしばらく停止しますが、クライアントプログラムが電子メールを送信すると、デーモンが再起動されると、電子メールは処理のためにキューに入れ続けます。
一方、他のサーバーがこのサーバーに接続しようとしましたが、アップグレードが進行中で応答を受け取らなかった場合、他のサーバーは電子メールをキューに入れ、しばらくして再試行します。電子メール配信は非常に安定して設計されています（ほとんどの場合、スパムやスパム対策の影響により以前ほど安定していませんが）。
他の種類のソフトウェアでは、デーモンの再起動中にしばらくダウンタイムが発生する可能性があります。これらのダウンタイムは通常、複数のサーバーシステムを保持し、それらの間の接続のバランスをとることによって処理されます。それにもかかわらず、これらの冗長性は高可用性システムに必要です（ハードウェアエラーは常に可能です）。
答え4
ダウンタイムなしでアップデートできるソフトウェアがあります。したがって、ソフトウェアは2つのバージョン、つまり新しいバージョンと古いバージョンを同時に実行できる必要があります。更新中も、以前のバージョンは接続されたクライアントにサービスを提供し続けます。更新後、新しいバージョンは制御を受け取り、新しいクライアントを処理します。以前のバージョンは、最後のクライアントの接続が切断された後に閉じて削除されることがあります（または新しいバージョンが正しく機能しない場合は、エレガントなパフォーマンス低下メカニズムが実装され、代替モードでバックグラウンドに残る可能性があります）。されました。ユースケースはほとんどありません。
そうでなければ、解雇に対するジョーダンの発言は正しいです。