「Systemd/ジャーナル」の版間の差分
(→フィルタリング: 情報を更新) |
細 (脱字の修正 (何も対応が必要な通常のメッセージ -> 何も対応が必要ない通常のメッセージ)) |
||
33行目: | 33行目: | ||
| 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"}}。 |
2023年9月7日 (木) 08:44時点における版
メインの記事は 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(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 のブログ記事 を見て下さい。
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(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
次を実行して journald を再起動してください:
# systemctl restart systemd-journald
別のジャーナルを指定して表示
ライブ環境から起動して本番環境を修復する場合など、トラブルが発生した他のシステムのログを確認する必要があるような場合、/mnt
などにディスクをマウントしてから、ジャーナルのパスを -D
/--directory
で指定することができます:
$ journalctl -D /mnt/var/log/journal -e
ユーザーとしてジャーナルアクセス
デフォルトでは、一般ユーザは自分のユーザ単位のジャーナルにしかアクセスできません。一般ユーザーとしてシステムジャーナルの読み込みアクセスを許可するには、そのユーザーを systemd-journal
に追加してください。ユーザーグループ adm
および wheel
グループのメンバにも読み込み権限が与えられます。
詳しくは、journalctl(1) § DESCRIPTION と ユーザーとグループ#ユーザーグループを参照してください。