「Systemd/ジャーナル」の版間の差分

提供: ArchWiki
ナビゲーションに移動 検索に移動
 
(3人の利用者による、間の14版が非表示)
7行目: 7行目:
 
メインの記事は [[systemd]] を参照。
 
メインの記事は [[systemd]] を参照。
   
''systemd'' は、バージョン 38 からのログシステムである journal 搭載しています。従って、syslog デーモンをる必要はもはやありません。ログを読むには:
+
''systemd'' は、journal という独自のログシステムをっており別途ログデーモンを動作させる必要はありません。ログを読むには、{{man|1|journalctl}} を使用します。
   
  +
Arch Linux では、{{ic|/var/log/journal/}} ディレクトリは {{Pkg|systemd}} パッケージの一部で、journal は({{ic|/etc/systemd/journald.conf}} で {{ic|1=Storage=}} が {{ic|auto}} に設定されている場合){{ic|/var/log/journal/}} に書き込みます。もし該当ディレクトリが削除された場合、''systemd'' はそれを自動的に再生成せず、代わりに {{ic|/run/systemd/journal}} に非永続的な方式でログを書き込みます。ただし、{{ic|journald.conf}} に {{ic|1=Storage=persistent}} が追加され、{{ic|systemd-journald.service}} が[[再起動]]された(またはシステムが再起動した)場合、ディレクトリは再生成されます。
# journalctl
 
   
  +
Systemd ジャーナルはメッセージを[[#プライオリティレベル|プライオリティレベル]]と[[#ファシリティ|ファシリティ]]で分類します。古典的な [[wikipedia:Syslog|Syslog]] プロトコルに対応しています ([https://tools.ietf.org/html/rfc5424 RFC 5424])。
デフォルトで ({{ic|/etc/systemd/journald.conf}} 内で {{ic|Storage=}} が {{ic|auto}} に設定されているとき)、journal は {{ic|/var/log/journal/}} へ書き込みを行います。Arch Linux では {{ic|/var/log/journal/}} ディレクトリは {{Pkg|systemd}} の一部であり、あなたや何らかのプログラムがディレクトリを削除した場合、systemd は自動で'''再作成しません'''が、systemd のアップデートがあるとディレクトリは作りなおされます。それまでログは代わりに {{ic|/run/systemd/journal}} に書き込まれます。ただし再起動時にこのログは消失してしまいます。
 
 
Systemd ジャーナルはメッセージを[[#プライオリティレベル|プライオリティレベル]]と[[#ファシリティ|ファシリティ]]で分類します。古典的な [[wikipedia:Syslog|Syslog]] プロトコルと対応しています ([https://tools.ietf.org/html/rfc5424 RFC 5424])。
 
   
 
==プライオリティレベル==
 
==プライオリティレベル==
23行目: 21行目:
 
! 値 !! 重大度 !! キーワード !! 説明 || 例
 
! 値 !! 重大度 !! キーワード !! 説明 || 例
 
|-
 
|-
| 0 || Emergency || emerg || システムは利用不可能 || 重大なカーネルバグ/systemd によってコアダンプが作成された。アプリケーション使用するレベルはありません
+
| 0 || Emergency || emerg || システムは利用不可能 || 重大なカーネルバグ、[[コアダンプ|systemd コアダンプ]]<br>このレベルはアプリケーションでは使用しないください
 
|-
 
|-
| 1 || Alert || alert || 即時対応が必要 || 重要なサブシステムが機能していない/データが消失している。<br>{{ic|kernel: BUG: unable to handle kernel paging request at ffffc90403238ffc}}
+
| 1 || Alert || alert || 即時対応が必要 || 重要なサブシステムが機能していない/データが消失している。<br>{{ic|kernel: BUG: unable to handle kernel paging request at ffffc90403238ffc}}
 
|-
 
|-
| 2 || Critical || crit || 緊急状態 || クラッシュ/コアダンプ{{ic|systemd-coredump[25319]: Process 25310 (plugin-containe) of user 1000 dumped core}}X11 などのシステムにとって重要なアプリケーションが機能を失っている。
+
| 2 || Critical || crit || 緊急状態 || クラッシュ/コアダンプ:<br>{{ic|systemd-coredump[25319]: Process 25310 (plugin-containe) of user 1000 dumped core}}<br>X11 などのシステムのプライマリアプリケーションでの障害
 
|-
 
|-
| 3 || Error || err || エラー状態 || 重大度いエラー: {{ic|kernel: usb 1-3: 3:1: cannot get freq at ep 0x84}},<br>{{ic|systemd[1]: Failed unmounting /var.}}, {{ic|libvirtd[1720]: internal error: Failed to initialize a valid firewall backend}})。
+
| 3 || Error || err || エラー状態 || 致命的でいエラー報告:<br>{{ic|kernel: usb 1-3: 3:1: cannot get freq at ep 0x84}},<br>{{ic|systemd[1]: Failed unmounting /var.}},<br>{{ic|libvirtd[1720]: internal error: Failed to initialize a valid firewall backend}}
 
|-
 
|-
| 4 || Warning || warning || エラーが発生する前に対応が必要 || ルートファイルシステム以外のファイルシステムの空き領域が 1GB しかない。{{ic|org.freedesktop. Notifications[1860]: (process:5999): Gtk-WARNING **: Locale not supported by C library. Using the fallback 'C' locale}}
+
| 4 || Warning || warning || エラーが発生する前に対応が必要 || ルートファイルシステム以外のファイルシステムの空き領域が 1GB しかない。{{ic|org.freedesktop. Notifications[1860]: (process:5999): Gtk-WARNING **: Locale not supported by C library. Using the fallback 'C' locale}}
 
|-
 
|-
| 5 || Notice || notice || 通常ではないイベントが発生しているがエラー状態ではない || {{ic|systemd[1]: var.mount: Directory /var to mount over is not empty, mounting anyway}}, {{ic|gcr-prompter[4997]: Gtk: GtkDialog mapped without a transient parent. This is discouraged}}
+
| 5 || Notice || notice || 通常ではないイベントが発生しているがエラー状態ではない || {{ic|systemd[1]: var.mount: Directory /var to mount over is not empty, mounting anyway}}, {{ic|gcr-prompter[4997]: Gtk: GtkDialog mapped without a transient parent. This is discouraged}}
 
|-
 
|-
| 6 || Informational || info || 何も対応が必要な通常のメッセージ || {{ic|lvm[585]: 7 logical volume(s) in volume group "archvg" now active}}
+
| 6 || Informational || info || 何も対応が必要な通常のメッセージ || {{ic|lvm[585]: 7 logical volume(s) in volume group "archvg" now active}}
 
|-
 
|-
| 7 || Debug || debug || アプリケーションをデバッグするのに役立つ情報 || {{ic|kdeinit5[1900]: powerdevil: Scheduling inhibition from ":1.14" "firefox" with cookie 13 and reason "screen"}}
+
| 7 || Debug || debug || アプリケーションをデバッグするのに役立つ情報 || {{ic|kdeinit5[1900]: powerdevil: Scheduling inhibition from ":1.14" "firefox" with cookie 13 and reason "screen"}}
 
|}
 
|}
   
106行目: 104行目:
 
例:
 
例:
   
  +
* 一致するすべてのメッセージを表示 {{ic|''PATTERN''}}: {{bc|1=# journalctl --grep=''PATTERN''}}
 
* 起動時からの全てのメッセージを表示: {{bc|# journalctl -b}} 場合によっては最新のブートメッセージではなく、以前のブートのメッセージを読みたいことがあります (例えば復旧できないシステムクラッシュが起こった場合)。{{ic|-b}} フラグに任意のパラメータを付けることでメッセージをオフセットして読むことが可能です: {{ic|journalctl -b -0}} は最新のブートのメッセージを、{{ic|journalctl -b -1}} は一つ前のブートのメッセージを表示し {{ic|journalctl -b -2}} は二つ前、と続きます。{{ic|journalctl --list-boots}} を使うことで数字を確認できます。詳しくは {{man|1|journalctl}} を見て下さい、セマンティックスはより強力です。
 
* 起動時からの全てのメッセージを表示: {{bc|# journalctl -b}} 場合によっては最新のブートメッセージではなく、以前のブートのメッセージを読みたいことがあります (例えば復旧できないシステムクラッシュが起こった場合)。{{ic|-b}} フラグに任意のパラメータを付けることでメッセージをオフセットして読むことが可能です: {{ic|journalctl -b -0}} は最新のブートのメッセージを、{{ic|journalctl -b -1}} は一つ前のブートのメッセージを表示し {{ic|journalctl -b -2}} は二つ前、と続きます。{{ic|journalctl --list-boots}} を使うことで数字を確認できます。詳しくは {{man|1|journalctl}} を見て下さい、セマンティックスはより強力です。
  +
* 利用可能な場合は、メッセージカタログからのログメッセージの説明を含めます: {{bc|#journalctl -x}} ログをバグレポートやサポートスレッドに添付する場合は、無関係な出力を制限するため、この機能を使用しないでください。{{ic|journalctl --list-catalog}} を実行すると、既知のカタログエントリをすべてリストできます。
 
* 特定の日付 (任意で時間も指定可能) からのメッセージを全て表示: {{bc|1=# journalctl --since="2012-10-30 18:17:16"}}
 
* 特定の日付 (任意で時間も指定可能) からのメッセージを全て表示: {{bc|1=# journalctl --since="2012-10-30 18:17:16"}}
 
* 20分前からのメッセージを全て表示: {{bc|1=# journalctl --since "20 min ago"}}
 
* 20分前からのメッセージを全て表示: {{bc|1=# journalctl --since "20 min ago"}}
116行目: 116行目:
 
* プライオリティレベルがエラー・クリティカル・アラートのメッセージだけを表示: {{bc|# journalctl -p err..alert}} {{ic|journalctl -p 3..1}} と数字を使うこともできます。{{ic|journalctl -p 3}} のようにひとつだけ指定した場合、指定されたプライオリティよりも高いレベルのメッセージも表示されます。
 
* プライオリティレベルがエラー・クリティカル・アラートのメッセージだけを表示: {{bc|# journalctl -p err..alert}} {{ic|journalctl -p 3..1}} と数字を使うこともできます。{{ic|journalctl -p 3}} のようにひとつだけ指定した場合、指定されたプライオリティよりも高いレベルのメッセージも表示されます。
 
* syslog の facility をフィルタリングすることで {{ic|auth.log}} と同等の内容を表示: {{bc|1=# journalctl SYSLOG_FACILITY=10}}
 
* syslog の facility をフィルタリングすることで {{ic|auth.log}} と同等の内容を表示: {{bc|1=# journalctl SYSLOG_FACILITY=10}}
  +
* ジャーナルディレクトリ (デフォルトでは {{ic|/var/log/journal}} にあります) に大量のログデータが含まれている場合、{{ic|journalctl}} が出力をフィルタリングするのに数分かかることがあります。{{ic|--file}} オプションを使用して、{{ic|journalctl}} が最新のジャーナルのみを参照するように強制すると、大幅に高速化できます: {{bc|# journalctl --file /var/log/journal /*/system.journal -f}}
   
 
詳しくは {{man|1|journalctl}}, {{man|7|systemd.journal-fields}} や Lennart の[http://0pointer.de/blog/projects/journalctl.html ブログ記事] を見て下さい。
 
詳しくは {{man|1|journalctl}}, {{man|7|systemd.journal-fields}} や Lennart の[http://0pointer.de/blog/projects/journalctl.html ブログ記事] を見て下さい。
   
 
{{Tip|1=
 
{{Tip|1=
デフォルトで、''journalctl'' は画面からはみ出る行を切り詰めますが、場合によっては、折り返しが有効になっていたほうが読みやすいことがあります。{{ic|SYSTEMD_LESS}} [[環境変数]]によってこれを制御することができ、[[Core Utilities#less|less]] (デフォルトのページャ) に渡すオプションを指定します。デフォルトは {{ic|FRSXMK}} です (詳しくは {{man|1|less}} や {{man|1|journalctl}} を参照)
+
デフォルトで、''journalctl'' は画面からはみ出る行を切り詰めますが、場合によっては、折り返しが有効になっていたほうが読みやすいことがあります。{{ic|SYSTEMD_LESS}} [[環境変数]]によってこれを制御することができ、[[Core Utilities#less|less]] (デフォルトのページャ) に渡すオプションを指定します。デフォルトは {{ic|FRSXMK}} です (詳しくは {{man|1|less}} や {{man|1|journalctl}} を参照)
   
 
{{ic|S}} オプションを省くことで、出力は折り返されるようになります。例えば、以下のように ''journalctl'' を起動してください:
 
{{ic|S}} オプションを省くことで、出力は折り返されるようになります。例えば、以下のように ''journalctl'' を起動してください:
133行目: 134行目:
 
== journal のサイズ制限 ==
 
== journal のサイズ制限 ==
   
journal が永続的(不揮発性)の場合、デフォルトではファイルシステムの容量の 10% に制限されます (4 GiB が上限)。例えば、{{ic|/var/log/journal}} が 20GiB の root パーティションにのっている場合、2GiB がログデータの上限になります。{{ic|/etc/systemd/journald.conf}} の {{ic|SystemMaxUse}} を変更すれば、最大サイズを変更できます。例えば制限を 50Mib にする場合適切な行を次ようにアンコメン・編集ます:
+
journal が永続的(不揮発性)の場合、デフォルトではファイルシステムの容量の 10% に制限されます (4 GiB が上限)。例えば、{{ic|/var/log/journal}} が 20GiB の root パーティションにのっている場合、2GiB がログデータの上限になります。{{ic|/etc/systemd/journald.conf}} の {{ic|SystemMaxUse}} を変更すれば、最大サイズを変更できます。システムでの現在の制限を確認するにはsystemd-journald ユニッログを確認て下さい。
   
  +
# journalctl -b -u systemd-journald
SystemMaxUse=50M
 
  +
  +
例えば制限を 50Mib にする場合、適切な行を次のようにアンコメント・編集します:
  +
  +
{{hc|/etc/systemd/journald.conf|2=
  +
SystemMaxUse=50M}}
   
 
上記のように設定ファイルを編集する代わりにドロップインファイルを使用する方法もあります。その場合 {{ic|[Journal]}} ヘッダーを使って以下のように記述してください:
 
上記のように設定ファイルを編集する代わりにドロップインファイルを使用する方法もあります。その場合 {{ic|[Journal]}} ヘッダーを使って以下のように記述してください:
143行目: 149行目:
 
SystemMaxUse=50M
 
SystemMaxUse=50M
 
}}
 
}}
  +
  +
この設定を変更した後、新しい設定を適用するために {{ic|systemd-journald.service}} を [[再起動]] してください。
   
 
詳細は {{man|5|journald.conf}} を参照してください。
 
詳細は {{man|5|journald.conf}} を参照してください。
  +
  +
=== ユニット単位でのサイズ制限 ===
  +
  +
設定したいサービス(例えば sshd)のユニットファイルを [[systemd#ユニットファイルの編集|編集]] して、{{ic|1=LogNamespace=ssh}} セクションを追加してください。
  +
  +
次に {{ic|/etc/systemd/journald.conf}} をコピーして {{ic|/etc/systemd/journald@ssh.conf}} を作成します。その後、{{ic|journald@ssh.conf}} を編集し、{{ic|SystemMaxUse}} を好みに合わせて調整します。
  +
  +
サービスを [[再起動]] すると、自動的に新しいジャーナルサービス {{ic|systemd-journald@ssh.service}} が開始されるはずです。名前空間サービスからのログは {{ic|journalctl --namespace ssh}} で見ることができます。
  +
  +
ジャーナルネームスペースの詳細については {{man|8|systemd-journald.service|JOURNAL NAMESPACES}} を参照してください。
   
 
== ジャーナルファイルを手動で消去 ==
 
== ジャーナルファイルを手動で消去 ==
152行目: 170行目:
 
* 使用ディスク容量が 100M 以下になるまで journal ファイルを削除する: {{bc|1=# journalctl --vacuum-size=100M}}
 
* 使用ディスク容量が 100M 以下になるまで journal ファイルを削除する: {{bc|1=# journalctl --vacuum-size=100M}}
 
* 2週間以上前のデータを含んでいる journal ファイルを削除する: {{bc|1=# journalctl --vacuum-time=2weeks}}
 
* 2週間以上前のデータを含んでいる journal ファイルを削除する: {{bc|1=# journalctl --vacuum-time=2weeks}}
  +
  +
ジャーナルファイルは、バキュームコマンドでトリミングする前に、ローテーションされて非アクティブになっている必要があります。ジャーナルファイルのローテーションは、{{ic|journalctl --rotate}} を実行することで実行できます。{{ic|--rotate}} 引数を 1 つ以上のバキューム基準引数と一緒に指定して、ローテーションを実行し、単一のコマンドでファイルをトリミングすることもできます。
   
 
詳しくは {{man|1|journalctl}} を見て下さい。
 
詳しくは {{man|1|journalctl}} を見て下さい。
157行目: 177行目:
 
== journald と syslog の結合 ==
 
== journald と syslog の結合 ==
   
古典的な [[syslog-ng|syslog]] との互換性は、すべてのメッセージがソケット {{ic|/run/systemd/journal/syslog}} 転送されることで実現されます。syslog を使うには、{{ic|/dev/log/}} の代わりにこのソケットを指定します ([https://lwn.net/Articles/474968/ 公式アナウンス])
+
従来のジャーナル非対応の [[Syslog-ng|syslog]] 実装との互換性は、''systemd'' がソケット {{ic|/run/systemd/journal/syslog}} 経由ですべてのメッセージを転送できるようにすることで実現できます。syslog デーモンジャーナルと連携させるには、{{ic|/dev/log}} ではなくこのソケットにバインドする必要があります([https://lwn.net/Articles/474968/ 公式アナウンス])
   
''systemd'' 216 からオーバーヘッドを減らすために {{ic|journald.conf}} のソケットの転送デフォルトで無効になっています ({{ic|1=ForwardToSyslog=no}})。[[rsyslog]] や [[syslog-ng]] (3.6 以降) は [https://lists.freedesktop.org/archives/systemd-devel/2014-August/022295.html#journald 自力で] journal からメッセージを取得するためです。
+
[[rsyslog]] または [[syslog-ng]] がプルされるため、システムのオーバーヘッドを避けるために、ソケットに転送するためのデフォルトの {{ic|journald.conf}} は {{ic|1=ForwardToSyslog=no}} です。 [https://lists.freedesktop.org/archives/systemd-devel/2014-August/022295.html#journald 自力で] journal からメッセージを取得するためです。
   
 
設定の詳細は [[Syslog-ng#概要]], [[Syslog-ng#syslog-ng と systemd journal]], [[rsyslog]] を見て下さい。
 
設定の詳細は [[Syslog-ng#概要]], [[Syslog-ng#syslog-ng と systemd journal]], [[rsyslog]] を見て下さい。
166行目: 186行目:
   
 
[[systemd#ユニットファイルの編集|ドロップインディレクトリ]] {{ic|/etc/systemd/journald.conf.d}} を作成して、ディレクトリの中に {{ic|fw-tty12.conf}} ファイルを作成してください:
 
[[systemd#ユニットファイルの編集|ドロップインディレクトリ]] {{ic|/etc/systemd/journald.conf.d}} を作成して、ディレクトリの中に {{ic|fw-tty12.conf}} ファイルを作成してください:
  +
 
{{hc|1=/etc/systemd/journald.conf.d/fw-tty12.conf|2=
 
{{hc|1=/etc/systemd/journald.conf.d/fw-tty12.conf|2=
 
[Journal]
 
[Journal]
173行目: 194行目:
 
}}
 
}}
   
を実行して journald を再起動してください:
+
{{ic|systemd-journald.service}} [[再起動]] してさい
  +
# systemctl restart systemd-journald
 
  +
{{Note|[https://github.com/systemd/systemd/issues/5129 設計上], カーネルのリングログメッセージは転送されません。}}
   
 
== 別のジャーナルを指定して表示 ==
 
== 別のジャーナルを指定して表示 ==
184行目: 206行目:
   
 
デフォルトでは、一般ユーザは自分のユーザ単位のジャーナルにしかアクセスできません。一般ユーザーとしてシステムジャーナルの読み込みアクセスを許可するには、そのユーザーを {{ic|systemd-journal}} に追加してください。[[ユーザーとグループ#グループ管理|ユーザーグループ]] {{ic|adm}} および {{ic|wheel}} グループのメンバにも読み込み権限が与えられます。
 
デフォルトでは、一般ユーザは自分のユーザ単位のジャーナルにしかアクセスできません。一般ユーザーとしてシステムジャーナルの読み込みアクセスを許可するには、そのユーザーを {{ic|systemd-journal}} に追加してください。[[ユーザーとグループ#グループ管理|ユーザーグループ]] {{ic|adm}} および {{ic|wheel}} グループのメンバにも読み込み権限が与えられます。
  +
  +
詳しくは、{{man|1|journalctl|DESCRIPTION}} と [[ユーザーとグループ#ユーザーグループ]]を参照してください。

2024年3月5日 (火) 23:54時点における最新版

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

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

Arch Linux では、/var/log/journal/ ディレクトリは systemd パッケージの一部で、journal は(/etc/systemd/journald.confStorage=auto に設定されている場合)/var/log/journal/ に書き込みます。もし該当ディレクトリが削除された場合、systemd はそれを自動的に再生成せず、代わりに /run/systemd/journal に非永続的な方式でログを書き込みます。ただし、journald.confStorage=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.confSystemMaxUse を変更すれば、最大サイズを変更できます。システムでの現在の制限を確認するには、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.confForwardToSyslog=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ユーザーとグループ#ユーザーグループを参照してください。