「Systemd/ジャーナル」の版間の差分
Kusanaginoturugi (トーク | 投稿記録) (→ユーザーとしてジャーナルアクセス: 英語版より記事を転載) |
Kusanaginoturugi (トーク | 投稿記録) (→ユーザーとしてジャーナルアクセス: 飜訳) |
||
202行目: | 202行目: | ||
デフォルトでは、一般ユーザは自分のユーザ単位のジャーナルにしかアクセスできません。一般ユーザーとしてシステムジャーナルの読み込みアクセスを許可するには、そのユーザーを {{ic|systemd-journal}} に追加してください。[[ユーザーとグループ#グループ管理|ユーザーグループ]] {{ic|adm}} および {{ic|wheel}} グループのメンバにも読み込み権限が与えられます。 |
デフォルトでは、一般ユーザは自分のユーザ単位のジャーナルにしかアクセスできません。一般ユーザーとしてシステムジャーナルの読み込みアクセスを許可するには、そのユーザーを {{ic|systemd-journal}} に追加してください。[[ユーザーとグループ#グループ管理|ユーザーグループ]] {{ic|adm}} および {{ic|wheel}} グループのメンバにも読み込み権限が与えられます。 |
||
− | + | 詳しくは、{{man|1|journalctl|DESCRIPTION}} と [[ユーザーとグループ#ユーザーグループ]]を参照してください。 |
2023年1月19日 (木) 14:21時点における版
メインの記事は 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
に書き込まれます。ただし再起動時にこのログは消失してしまいます。
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
を使って出力にフィルタをかけることができます。表示したりフィルタリングをするメッセージが大量にある場合、かなり時間がかかります。コマンドの出力は相当の時間がたってから表示されるかもしれません。
例:
- 起動時からの全てのメッセージを表示:
# 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 のブログ記事 を見て下さい。
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 との互換性は、すべてのメッセージがソケット /run/systemd/journal/syslog
に転送されることで実現されます。syslog を使うには、/dev/log/
の代わりにこのソケットを指定します (公式アナウンス)。
systemd 216 からオーバーヘッドを減らすために journald.conf
のソケットの転送はデフォルトで無効になっています (ForwardToSyslog=no
)。rsyslog や syslog-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 -e
ユーザーとしてジャーナルアクセス
デフォルトでは、一般ユーザは自分のユーザ単位のジャーナルにしかアクセスできません。一般ユーザーとしてシステムジャーナルの読み込みアクセスを許可するには、そのユーザーを systemd-journal
に追加してください。ユーザーグループ adm
および wheel
グループのメンバにも読み込み権限が与えられます。
詳しくは、journalctl(1) § DESCRIPTION と ユーザーとグループ#ユーザーグループを参照してください。