systemd/ジャーナル

提供: ArchWiki
2019年2月22日 (金) 00:43時点におけるKusakata (トーク | 投稿記録)による版
ナビゲーションに移動 検索に移動

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

systemd は、バージョン 38 から自前のログシステムである journal を搭載しています。従って、syslog デーモンを起動する必要はもはやありません。ログを読むには:

# journalctl

デフォルトで (/etc/systemd/journald.conf 内で Storage=auto に設定されているとき)、journal は /var/log/journal/ へ書き込みを行います。Arch Linux では /var/log/journal/ ディレクトリは systemd の一部であり、あなたや何らかのプログラムがディレクトリを削除した場合、systemd は自動で再作成しませんが、systemd のアップデートがあるとディレクトリは作りなおされます。それまでログは代わりに /run/systemd/journal に書き込まれます。ただし再起動時にこのログは消失してしまいます。

ヒント: /var/log/journal/btrfs ファイルシステムに存在する場合、ディレクトリの Copy-on-Write を無効にするべきです。詳しくは Btrfs#コピーオンライト (CoW) を読んで下さい。

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

ヒント: journal はバイナリ形式で保存されますが、保存されるメッセージの中身に修正は加わりません。このため、systemd をインストールしていない環境でリカバリなどをするために、strings を使って回覧することが可能です。コマンドの例: $ strings /mnt/arch/var/log/journal/af4967d77fba44c6b093d0e9862f6ddd/system.journal | grep -i message

例:

  • 起動時からの全てのメッセージを表示:
    # journalctl -b
    場合によっては最新のブートメッセージではなく、以前のブートのメッセージを読みたいことがあります (例えば復旧できないシステムクラッシュが起こった場合)。-b フラグに任意のパラメータを付けることでメッセージをオフセットして読むことが可能です: journalctl -b -0 は最新のブートのメッセージを、journalctl -b -1 は一つ前のブートのメッセージを表示し journalctl -b -2 は二つ前、と続きます。journalctl --list-boots を使うことで数字を確認できます。詳しくは journalctl(1) を見て下さい、セマンティックスはより強力です。
  • 特定の日付 (任意で時間も指定可能) からのメッセージを全て表示:
    # 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

詳しくは 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 のサイズ制限

journal が永続的(不揮発性)の場合、デフォルトではファイルシステムの容量の 10% に制限されます (4 GiB が上限)。例えば、/var/log/journal が 20GiB の root パーティションにのっている場合、2GiB がログデータの上限になります。/etc/systemd/journald.confSystemMaxUse を変更すれば、最大サイズを変更できます。例えば制限を 50Mib にする場合、適切な行を次のようにアンコメント・編集します:

SystemMaxUse=50M

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

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

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

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

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

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

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

journald と syslog の結合

古典的な syslog との互換性は、すべてのメッセージがソケット /run/systemd/journal/syslog に転送されることで実現されます。syslog を使うには、/dev/log/ の代わりにこのソケットを指定します (公式アナウンス)。

systemd 216 からオーバーヘッドを減らすために journald.conf のソケットの転送はデフォルトで無効になっています (ForwardToSyslog=no)。rsyslogsyslog-ng (3.6 以降) は 自力で 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

次を実行して journald を再起動してください:

# systemctl restart systemd-journald

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

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

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