1990年代半ばのdaemontoolsの主な革新の1つは証明されたトラック記録。デーモンスーパーバイザーが起動します。二つ保護者基本デーモンと丸太悪魔。パイプを呼び出す前に、パイプを開き、パイプの書き込み端を次のように提供します。基本デーモンの標準出力とパイプの読み取り端は次のような役割を果たします。丸太デーモンの標準入力。それ返品それ自体は、パイプの両端に開かれたファイル記述子を保持します。したがって、ログデーモンがシャットダウンまたはシャットダウンした後に再起動すると、パイプに書き込まれたログデータが保存され、パイプが閉じられないため、新しく再起動したログデーモンインスタンスから読み取りおよびログ記録できます。

systemdデザイナーはこのデザインで学ばなかった。

systemd生成されたサービスプロセス（設定されている場合）がソケットを介して標準出力をロギングプロセスに送信する準備をします。ただし、daemontoolsの場合と同様に、パイプを開き、各プロセスがパイプの適切な端を継承するように配置する代わりに、ストリームソケットがsystemd使用されます。デフォルトプロセスはクライアントとして接続され、ログプロセスはサーバーに受信されます。AF_LOCAL/run/systemd/journal/stdout

これは、データ接続に継承されたパイプセマンティクスではなく、クライアント - サーバーソケットセマンティクスがあることを意味します。サーバーが切断されると、接続は消えます。バッファリングされたすべてのログデータが失われ、すべてもっと遠くメインデーモンが書き込んだデータは閉じたソケットに入り、失われます。 （これがsystemdのデフォルト設定がtrueの理由の1つですIgnoreSIGPIPE。閉じたソケットにログ出力を書き込みます。返品カーネルがログに書き込んでいるデーモンを終了しようとします。 )

したがって、プロセスを終了すると、systemd-journaldプロセス出口は出力がログに記録されているすべてのデーモンへのソケット接続を閉じ、それ以降のすべての出力は失われます。これを回復し、基本プロセスの出力をログプロセスに再接続する方法はありません。systemd再開するには、すべての基本プロセスを再起動する必要があります。新しい（新しく作成された）ログサーバーへのクライアント接続。

systemdの人々は2016年に解決策を出しました。これには、選択した開いているファイル記述子をプロセス＃1にプッシュし、後で解決するプロセス機能を追加することが含まれます。 systemd-journaldロギングデーモン自体が再起動したときにクライアントが開いたままになるように、ロギングしているクライアントへのサーバー側接続を介してこれを行います。

このメカニズムの問題は、セキュリティを維持するために多くの作業が必要であり、今年の出来事だけで証明されているように、システムを持つ人々はセキュリティ設計に関する良い記録を持っていないことです。そのため、より多くの作業が必要です。WHO押すことができる何そしてどのくらい#1を処理するファイル記述子を開き、どのくらいの時間アクセス制御と制限が必要です。そうしないと、脆弱性がたくさん発生する可能性があります。 （daemontools設計では、サービスマネージャプロセス自体はファイルディスクリプタを開くオブジェクトであるため、サブプロセスに対して開いているファイルディスクリプタを絶対に制御できます。

Laurent Bercotのs6では、s6-svscan基本サービスとログサービスの間のパイプラインを使用して一般的なdaemontools操作が実行されます。また、任意のファイル記述子を開いたままにするメカニズムもあります。これは、systemdなど、プロセス＃1のサービスマネージャ内でスーパーユーザー権限で実行されるコードでは実行されません。これは、サービス管理者とは別に実行される完全に権限のないプロセスによって行われます。

追加読書

• マイケル聖書（2014-11-26）。再起動ログは他のサービスを中断します。。 Debianのバグ＃771122。
• https://unix.stackexchange.com/a/332315/5132
• https://unix.stackexchange.com/a/294206/5132
• ローランベルコ。s6-fdholderd。 s6。 skarnet.org.
• スティーブン・ライクリン（2015-12-28）。ログからの構成の再ロードのサポート。システムエラー＃2236。