stdout にログを記録する systemd サービスがあります。そこから、systemd は STDOUT をキャプチャし、それをジャーナルに書き込みます。
エラーを処理するための一般的な慣用句を使用して、echoいくつかの診断を行い、ゼロ以外のエラー コードで終了します。
echo "my final error";
exit 1;
問題は、この最終echo行がジャーナルに記録されるものの、私の「ユニット」に適切に関連付けられていないことです。 を見るとjournalctl -o json-pretty、違いがわかります。最終ログには、プロパティ _SYSTEMD_CGROUP と _SYSTEMD_UNIT がありません。
発生していると思われるのは、一種の競合状態です。bash スクリプトは、 がjournald完全に処理されるまで待たずに終了行に進んでしまうのではないかと考えています。そのため、 がログ エントリの処理を完了するexit前に 行に到達します。 は、ログを送信したを検索しようとしますが、ユニットがもう実行されていないため、見つけることができません。journaldjournaldunit
sleep 1私の考えが正しければ、ステートメントの前にを置くことで問題を回避できると思いますexit 1が、最終的なログ プロパティを属性として設定するより良い方法はありますか?
systemdUbuntu 16.04でバージョン229を使用しています。
答え1
@mark-stosberg、これは既知の問題です:journald は、/proc と SCM_CREDS の競合により、終了したプロセスから受信したメッセージを cgroup に帰属させることができません。
回避策はここにあります:https://github.com/systemd/systemd/issues/2913#issuecomment-219702148
ログ システムまたはカーネル ログ バッファーに送信されるログ行の先頭にプロセス名を設定します。
そして走る
journalctl _SYSTEMD_UNIT=unit + UNIT=unit + SYSLOG_IDENTIFIER=id
答え2
調べてみたところ、どうやらsystemdの既知の問題で、プルリクエストがある。
この修正には、サービスのメタデータをキャッシュすることが含まれます。これにより、サービスが終了した場合でも、そのメタデータは引き続き利用可能になり、最後のいくつかのログを適切に分類できるようになります。
また、CoreOS の未解決バグsystemd を使用します。
このバグは、systemd freedesktop.org バグトラッカーでも次のように追跡されています。
さらにテストを進めると、ログの帰属先が不明な問題は、ユーザーユニットは別の問題だと思います。システムユニットの場合、競合状態は比較的小さく、sleep 1;サービス スクリプトの終了直前に追加すると、最後のログが印刷されて終了する前に十分なパディングが追加され、問題が回避される可能性があります。