デーモンが起動時にのみ設定ファイルを読み取るのはなぜですか？そのファイル/ホットリロードの変更に「反応」できないのはなぜですか？ [閉鎖]

いくつかの理由があります。主な理由の1つは、多くのデーモンが複数の設定ファイルを持っていて、単一のファイル変更がそれ自体で機能しない可能性があることです。したがって、構成ファイルのいずれかが変更されるたびにデーモンの構成を再ロードしようとすると、解決されるよりも多くの問題が発生する可能性があります。質問。

純粋に実装の観点からは、構成ファイルの変更を監視する必要があると、デーモンはより複雑になります。デーモンには、デーモンの主な目的に対応するタスクが実行されることを確認する一種の中央ループがあります。構成ファイルの変更を確認することが必ずしもその重要な目的に合うわけではありません。

別々の信号を処理すると、両方の問題が解決されます。設定が一貫して再ロードされても安全であることをユーザーに通知し、メインループへの影響を最小限に抑えながら、シグナルハンドラ（通常はデフォルトフラグの変更）で非同期に実装できます。フラグの変更に反応します）。

一部のデーモンは設定変更自体に反応します。cronたとえば、基本ループが実行されるたびに、その構成ファイルの変更を確認します。

他の答えで言及されている他のすべての理由に加えて、より深い哲学的な理由があります。これは、基本的なUnixプログラミング設計の原則の1つです。何かをしてうまくいく。

Unixでは、プログラムは通常1つのことを行います。複数のプログラムを組み合わせることで、より複雑なタスクを実行できます。

今（例えば）ウェブサイトを提供することが1つになりました。ファイルの変更を見るのは別の話です。したがって、Unixのモットーによると、WebサーバーはたとえばWebサイトを提供するため、これらは2つの異なるプログラムでなければなりません。そしてファイルの変更を監視するのはうまくいきません何かをしてうまくいく、そうです二つ。多くの場合、2つのタスクを実行するプログラムは、少なくともこれら2つのタスクをうまく実行できません。 （たとえば、Webサーバーを作成する人はHTTPの専門家である可能性がありますが、ファイル監視の専門家ではないかもしれません。）

特にネットワーク指向デーモンの場合、「1つのタスクのみを実行する」原則に従う必要があるもう1つの理由がセキュリティです。すべてのコード行は潜在的なエラーです。最も安全なコードはコードがないことです。デーモンに属さないデーモンから責任を取り除くことで、コード量を減らし、それに伴う攻撃面を減らすことができます。

複数のタスクを実行するプログラムが通常、そのうちの1つ以上でパフォーマンスが低下するという事実に加えて、責任を共有するもう1つの理由があります。コードの再利用。ファイル監視がWebサーバーの一部である場合、SSHサーバーもファイル監視を実装する必要があります。そしてファイルサーバー。そしてチャットサーバー。そして電話サーバー。そしてデータベースサーバー。そしてメディアストリーミングサーバー。その他など

また、ファイルの監視が別のプログラムで行われる場合は、このプログラムを実装するだけです。一度、一度テスト、一度最適化、一度記録など。また、人々に使い方を一度だけ教育すれば適用できます。これまでに書かれたすべてのデーモン、実際にも将来作成されるすべてのデーモン。

だから、もし質問で求めたことをしたいです。二つデーモン：たとえば、Webサイトを提供するデーモン、ファイルの変更を監視し、その変更に応じて操作を実行するデーモンです。

そして驚くべきことに、そのようなデーモンはすでに存在しています。

他の答えを追加する：最大の障害の1つは、少なくともアプリケーションの現在の状態、以前の値、およびその他の変更された値を理解するために、各構成値に説明が必要であることです。通常、構成ファイルは、非実行状態から初期状態に入る方法をデーモンプロセスに指示します。デーモンが構成を変更したときに再ロードするということは、構成値をデーモンの現在の状態に対する変更として解釈できることを意味します。たとえば、ある種の作業デーモンを考えてみましょう。構成では、worker_threads: 2デーモンが始まったばかりの説明は簡単です。タスクを実行するために2つのスレッドが作成されます。この値に対する修正を処理する必要がある場合は、いくつかのことを行う必要があります。つまり、スレッド数が増えたら、さらにスレッドを追加する必要があります。減少したら、いくつかのスレッドを削除します。

変更の解釈は、以前の値だけでなくデーモンの現在の状態にも依存します。構成をに更新する場合、worker_threads: 1両方のスレッドが使用されている場合、デーモンはどうすればよいですか？構成で説明されている状態とすぐに一致するには、1つを終了する必要がありますか？ジョブが完了するまで実行された次のスレッドを終了することを許可する必要がありますか？

これに加えて、構成値の変更の解釈は、他の構成値の変更によって異なります。すべてのワーカースレッドが使用されているときにワーカースレッドの数を減らすときに実行するアクションを決定する追加の設定値があるとしますkill_threads_on_worker_reduction: true/false。設定すると、アクティブなワーカースレッドを終了するかどうかを決定できます。ただし、構成値が次の場合返品変わった？実行中の新しいジョブにのみ適用されますか、または変更前に開始されたジョブに遡って適用されますか？

これはただの研究だけです。一つ可能な構成値。すべての構成値、すべての可能なアプリケーション状況、および変更された値のすべての可能な組み合わせについて、それらを計算する必要があります。

場合によっては、構成変更が説明する方が簡単ですが、これは構成変更をライブに再ロードするのが簡単ではない理由を説明するのに役立ちます。