systemd/ジャーナル

提供: ArchWiki
（Journalctlから転送）
ナビゲーションに移動 検索に移動

メインの記事は systemd を参照。

systemd は、journal という独自のログシステムを持っており、別途ログデーモンを動作させる必要はありません。ログを読むには、journalctl(1) を使用します。

Arch Linux では、/var/log/journal/ ディレクトリは systemd パッケージの一部で、journal は（/etc/systemd/journald.conf で Storage= が auto に設定されている場合）/var/log/journal/ に書き込みます。もし該当ディレクトリが削除された場合、systemd はそれを自動的に再生成せず、代わりに /run/systemd/journal に非永続的な方式でログを書き込みます。ただし、journald.conf に Storage=persistent が追加され、systemd-journald.service が再起動された（またはシステムが再起動した）場合、ディレクトリは再生成されます。

Systemd ジャーナルはメッセージをプライオリティレベルとファシリティで分類します。古典的な Syslog プロトコルに対応しています (RFC 5424)。

プライオリティレベル

メッセージの重要度は syslog の重大度コード (systemd ではプライオリティと呼ばれます) を使って示されます RFC 5424 Section 6.2.1:

値 重大度 キーワード 説明 例
0 Emergency emerg システムは利用不可能 重大なカーネルバグ、systemd コアダンプ
このレベルはアプリケーションでは使用しないでください。
1 Alert alert 即時対応が必要 重要なサブシステムが機能していない/データが消失している。
kernel: BUG: unable to handle kernel paging request at ffffc90403238ffc
2 Critical crit 緊急状態 クラッシュ/コアダンプ:
systemd-coredump[25319]: Process 25310 (plugin-containe) of user 1000 dumped core
X11 などのシステムのプライマリアプリケーションでの障害
3 Error err エラー状態 致命的ではないエラー報告:
kernel: usb 1-3: 3:1: cannot get freq at ep 0x84,
systemd[1]: Failed unmounting /var.,
libvirtd[1720]: internal error: Failed to initialize a valid firewall backend
4 Warning warning エラーが発生する前に対応が必要 ルートファイルシステム以外のファイルシステムの空き領域が 1GB しかない。org.freedesktop. Notifications[1860]: (process:5999): Gtk-WARNING **: Locale not supported by C library. Using the fallback 'C' locale
5 Notice notice 通常ではないイベントが発生しているがエラー状態ではない systemd[1]: var.mount: Directory /var to mount over is not empty, mounting anyway, gcr-prompter[4997]: Gtk: GtkDialog mapped without a transient parent. This is discouraged
6 Informational info 何も対応が必要ない通常のメッセージ lvm[585]: 7 logical volume(s) in volume group "archvg" now active
7 Debug debug アプリケーションをデバッグするのに役立つ情報 kdeinit5[1900]: powerdevil: Scheduling inhibition from ":1.14" "firefox" with cookie 13 and reason "screen"

上記のレベルで問題が確認できない場合、上下のプライオリティレベルも調べてみてください。厳しくルールが決められているわけではありません。発生する確率が高いエラーは開発者によってプライオリティが低く設定されている可能性があります。逆に、緊急度が高いメッセージが大量に出力されることもありますが、必ずしも切羽詰まった状況を表しているとは限りません。

ファシリティ

メッセージを出力したプログラムのタイプは syslog のファシリティコードで指定されます RFC 5424 Section 6.2.1:

ファシリティコード キーワード 説明 情報
0 kern カーネルメッセージ
1 user ユーザーレベルメッセージ
2 mail メールシステム 詳しくは mail(1) を見てください。
3 daemon システムデーモン systemd やサブシステムを含む全てのデーモン
4 auth セキュリティ/認証メッセージ ファシリティ10もあります。
5 syslog syslogd の内部メッセージ syslogd 用のファシリティなので systemd は使用していません (ファシリティ3を使います)。
6 lpr ラインプリンターサブシステム (旧式のサブシステム)
7 news ネットワークニュースサブシステム (旧式のサブシステム)
8 uucp UUCP サブシステム (旧式のサブシステム)
9 クロックデーモン systemd-timesyncd
10 authpriv セキュリティ/認証メッセージ ファシリティ4もあります。
11 ftp FTP デーモン
12 - NTP サブシステム
13 - log audit
14 - log alert
15 cron スケジューリングデーモン
16 local0 ローカル使用 0 (local0)
17 local1 ローカル使用 1 (local1)
18 local2 ローカル使用 2 (local2)
19 local3 ローカル使用 3 (local3)
20 local4 ローカル使用 4 (local4)
21 local5 ローカル使用 5 (local5)
22 local6 ローカル使用 6 (local6)
23 local7 ローカル使用 7 (local7)

意味のあるファシリティは次の7つになります: 0, 1, 3, 4, 9, 10, 15。

フィルタリング

journalctl を使って出力にフィルタをかけることができます。表示したりフィルタリングをするメッセージが大量にある場合、かなり時間がかかります。コマンドの出力は相当の時間がたってから表示されるかもしれません。

例:

  • 一致するすべてのメッセージを表示 PATTERN: 
    # journalctl --grep=PATTERN
  • 起動時からの全てのメッセージを表示: 
    # journalctl -b
    場合によっては最新のブートメッセージではなく、以前のブートのメッセージを読みたいことがあります (例えば復旧できないシステムクラッシュが起こった場合)。-b フラグに任意のパラメータを付けることでメッセージをオフセットして読むことが可能です: journalctl -b -0 は最新のブートのメッセージを、journalctl -b -1 は一つ前のブートのメッセージを表示し journalctl -b -2 は二つ前、と続きます。journalctl --list-boots を使うことで数字を確認できます。詳しくは journalctl(1) を見て下さい、セマンティックスはより強力です。
  • 利用可能な場合は、メッセージカタログからのログメッセージの説明を含めます: 
    #journalctl -x
    ログをバグレポートやサポートスレッドに添付する場合は、無関係な出力を制限するため、この機能を使用しないでください。journalctl --list-catalog を実行すると、既知のカタログエントリをすべてリストできます。
  • 特定の日付 (任意で時間も指定可能) からのメッセージを全て表示: 
    # journalctl --since="2012-10-30 18:17:16"
  • 20分前からのメッセージを全て表示: 
    # journalctl --since "20 min ago"
  • 新しいメッセージを表示: 
    # journalctl -f
  • 特定の実行ファイルによる全てのメッセージを表示: 
    # journalctl /usr/lib/systemd/systemd
  • 特定のプロセスによる全てのメッセージを表示: 
    # journalctl _PID=1
  • 特定のユニットによる全てのメッセージを表示: 
    # journalctl -u netcfg
  • カーネルのリングバッファを表示: 
    # journalctl -k
  • プライオリティレベルがエラー・クリティカル・アラートのメッセージだけを表示: 
    # journalctl -p err..alert
    journalctl -p 3..1 と数字を使うこともできます。journalctl -p 3 のようにひとつだけ指定した場合、指定されたプライオリティよりも高いレベルのメッセージも表示されます。
  • syslog の facility をフィルタリングすることで auth.log と同等の内容を表示: 
    # journalctl SYSLOG_FACILITY=10
  • ジャーナルディレクトリ (デフォルトでは /var/log/journal にあります) に大量のログデータが含まれている場合、journalctl が出力をフィルタリングするのに数分かかることがあります。--file オプションを使用して、journalctl が最新のジャーナルのみを参照するように強制すると、大幅に高速化できます: 
    # journalctl --file /var/log/journal /*/system.journal -f

詳しくは journalctl(1), systemd.journal-fields(7) や Lennart のブログ記事 を見て下さい。

ヒント: デフォルトで、journalctl は画面からはみ出る行を切り詰めますが、場合によっては、折り返しが有効になっていたほうが読みやすいことがあります。SYSTEMD_LESS 環境変数によってこれを制御することができ、less (デフォルトのページャ) に渡すオプションを指定します。デフォルトは FRSXMK です (詳しくは less(1) や journalctl(1) を参照)

S オプションを省くことで、出力は折り返されるようになります。例えば、以下のように journalctl を起動してください: 

$ SYSTEMD_LESS=FRXMK journalctl
この挙動をデフォルトに設定したいならば、~/.bashrc や ~/.zshrc でこの変数を export してください。
ヒント: journal はバイナリ形式で保存されますが、保存されるメッセージの中身に修正は加わりません。このため、systemd をインストールしていない環境でリカバリなどをするために、strings を使って回覧することが可能です。コマンドの例: $ strings /mnt/arch/var/log/journal/af4967d77fba44c6b093d0e9862f6ddd/system.journal | grep -i message

journal のサイズ制限

journal が永続的（不揮発性）の場合、デフォルトではファイルシステムの容量の 10% に制限されます (4 GiB が上限)。例えば、/var/log/journal が 20GiB の root パーティションにのっている場合、2GiB がログデータの上限になります。/etc/systemd/journald.conf の SystemMaxUse を変更すれば、最大サイズを変更できます。システムでの現在の制限を確認するには、systemd-journald のユニットログを確認して下さい。 

# journalctl -b -u systemd-journald

例えば制限を 50Mib にする場合、適切な行を次のようにアンコメント・編集します: 

/etc/systemd/journald.conf
SystemMaxUse=50M

上記のように設定ファイルを編集する代わりにドロップインファイルを使用する方法もあります。その場合 [Journal] ヘッダーを使って以下のように記述してください: 

/etc/systemd/journald.conf.d/00-journal-size.conf
[Journal]
SystemMaxUse=50M

この設定を変更した後、新しい設定を適用するために systemd-journald.service を 再起動 してください。

詳細は journald.conf(5) を参照してください。

ユニット単位でのサイズ制限

設定したいサービス（例えば sshd）のユニットファイルを 編集 して、LogNamespace=ssh セクションを追加してください。

次に /etc/systemd/journald.conf をコピーして /etc/systemd/journald@ssh.conf を作成します。その後、journald@ssh.conf を編集し、SystemMaxUse を好みに合わせて調整します。

サービスを 再起動 すると、自動的に新しいジャーナルサービス systemd-journald@ssh.service が開始されるはずです。名前空間サービスからのログは journalctl --namespace ssh で見ることができます。

ジャーナルネームスペースの詳細については systemd-journald.service(8) § JOURNAL NAMESPACES を参照してください。

ジャーナルファイルを手動で消去

journal のファイルは /var/log/journal に存在します。rm で消去することもできますが、journalctl を使って消去することも可能です。例:

  • 使用ディスク容量が 100M 以下になるまで journal ファイルを削除する: 
    # journalctl --vacuum-size=100M
  • 2週間以上前のデータを含んでいる journal ファイルを削除する: 
    # journalctl --vacuum-time=2weeks

ジャーナルファイルは、バキュームコマンドでトリミングする前に、ローテーションされて非アクティブになっている必要があります。ジャーナルファイルのローテーションは、journalctl --rotate を実行することで実行できます。--rotate 引数を 1 つ以上のバキューム基準引数と一緒に指定して、ローテーションを実行し、単一のコマンドでファイルをトリミングすることもできます。

詳しくは journalctl(1) を見て下さい。

journald と syslog の結合

従来のジャーナル非対応の syslog 実装との互換性は、systemd がソケット /run/systemd/journal/syslog 経由ですべてのメッセージを転送できるようにすることで実現できます。syslog デーモンをジャーナルと連携させるには、/dev/log ではなくこのソケットにバインドする必要があります。(公式アナウンス)

rsyslog または syslog-ng がプルされるため、システムのオーバーヘッドを避けるために、ソケットに転送するためのデフォルトの journald.conf は ForwardToSyslog=no です。 自力で journal からメッセージを取得するためです。

設定の詳細は Syslog-ng#概要, Syslog-ng#syslog-ng と systemd journal, rsyslog を見て下さい。

journald を /dev/tty12 に転送する

ドロップインディレクトリ /etc/systemd/journald.conf.d を作成して、ディレクトリの中に fw-tty12.conf ファイルを作成してください: 

/etc/systemd/journald.conf.d/fw-tty12.conf
[Journal]
ForwardToConsole=yes
TTYPath=/dev/tty12
MaxLevelConsole=info

次に systemd-journald.service を 再起動 して下さい。

ノート: 設計上, カーネルのリングログメッセージは転送されません。

別のジャーナルを指定して表示

ライブ環境から起動して本番環境を修復する場合など、トラブルが発生した他のシステムのログを確認する必要があるような場合、/mnt などにディスクをマウントしてから、ジャーナルのパスを -D/--directory で指定することができます: 

$ journalctl -D /mnt/var/log/journal -e

ユーザーとしてジャーナルアクセス

デフォルトでは、一般ユーザは自分のユーザ単位のジャーナルにしかアクセスできません。一般ユーザーとしてシステムジャーナルの読み込みアクセスを許可するには、そのユーザーを systemd-journal に追加してください。ユーザーグループ adm および wheel グループのメンバにも読み込み権限が与えられます。

詳しくは、journalctl(1) § DESCRIPTION と ユーザーとグループ#ユーザーグループを参照してください。

「https://wiki.archlinux.jp/index.php?title=Systemd/ジャーナル&oldid=36445」から取得