トレーサビリティ、責任性などを改善するために、特定のアプリケーションをsystemdで監視し、その出力をログに収集したいと思います。 systemd-runのサービスモードを使用すると、これらすべてが自動的に発生することがわかりますが、呼び出し環境への依存関係のため、これは不可能です。
私はsystemd-runとsystemd-catの両方を試しましたが、残念ながらユニットメタデータをキャプチャしません。理論的には、envプロセスを開始する前に環境変数をファイルにダンプしてからsystemd-runに渡すことができますが、EnvironmentFile=これはハッキングのように見えます。必須変数（ファイル記述子など）に加えて、実行環境に他のデータがある場合でも失敗します。しかし、これは比較的まれな要件です。シェルパイプ（最も一般的なタイプの共有ファイル記述子）は通常シェルパイプに置き換えることができます。一時的に名前付きパイプまたはファイル。
私はハッキングされた方法を使用することを気にするのではなく、「既知の良い」代替案があるかどうか疑問に思います。
編集：コメントが要求されたので、私が探しているメタデータフィールドは_SYSTEMD_UNIT、_SYSTEMD_SLICEなどであり、_AUDIT_LOGINUID通常は監督プロセスのために収集されるその他のメタ_CAP_EFFECTIVEデータです。 Podman / conmonコンテナログを見ると、sd_journal_sendv範囲単位内で手動で生成されたにもかかわらず、完全なメタデータを持つ範囲単位を使用してこれが可能であることがわかりました。また、ソースコードを確認しましたが、logger(1)同じ機能を使用するので、ログが存在しないsystemd-runとの相関関係を設定するようにするpodman/conmonの単位設定に何かがあると仮定します。
ベストアンサー1
systemd-run --scopeさらなる実験は、特定のエッジケースを除いて、レイヤーが実際にメタデータを正しくキャプチャすることを発見しましたsystemd-cat。テスト範囲が狭すぎて、その目標を正確に達成しました。
詳しくは、ジャーナルが着信メッセージを処理するのにかかる時間と、systemdガベージコレクションが終了した後に範囲単位をクリーンアップするのにかかる時間との間に競合状態がある可能性があります。
テストでは、両方のツールに長期実行プロセスを含めるか、ワンタイムコマンドの最後にスリープモードを追加すると、ログエントリがセルメタデータなどで適切に強化されます。ただし、.pipesystemd-catに渡されたを使用する必要がある "exec"型は機能しません。--シェルを開きsystemd-run --scope、コマンドを実行し、出力を systemd-cat でパイプしてみました。上記の競合状態を回避するために、パイプラインの後ろにスリープを追加しましたが、生成されたジャーナル項目にはセルメタデータが豊富ではありませんでした。