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

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

メインの記事は 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)。

1 プライオリティレベル
2 ファシリティ
3 フィルタリング
4 journal のサイズ制限
- 4.1 ユニット単位でのサイズ制限
5 ジャーナルファイルを手動で消去
6 journald と syslog の結合
7 journald を /dev/tty12 に転送する
8 別のジャーナルを指定して表示
9 ユーザーとしてジャーナルアクセス

プライオリティレベル

メッセージの重要度は 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 とユーザーとグループ#ユーザーグループを参照してください。

@@ 7行目: / 7行目: @@
 メインの記事は [[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&#61;}} が {{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 -x}} ログをバグレポートやサポートスレッドに添付する場合は、無関係な出力を制限するため、この機能を使用しないでください。{{ic|journalctl --list-catalog}} を実行すると、既知のカタログエントリをすべてリストできます。
 * 特定の日付 (任意で時間も指定可能) からのメッセージを全て表示: {{bc|1=# journalctl --since="2012-10-30 18:17:16"}}
 * 20分前からのメッセージを全て表示: {{bc|1=# journalctl --since "20 min ago"}}
@@ 116行目: / 116行目: @@
 * プライオリティレベルがエラー・クリティカル・アラートのメッセージだけを表示: {{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}}
+* ジャーナルディレクトリ (デフォルトでは {{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 ブログ記事] を見て下さい。
 {{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'' を起動してください:
@@ 169行目: / 170行目: @@
 * 使用ディスク容量が 100M 以下になるまで journal ファイルを削除する: {{bc|1=# journalctl --vacuum-size=100M}}
 * 2週間以上前のデータを含んでいる journal ファイルを削除する: {{bc|1=# journalctl --vacuum-time=2weeks}}
+ジャーナルファイルは、バキュームコマンドでトリミングする前に、ローテーションされて非アクティブになっている必要があります。ジャーナルファイルのローテーションは、{{ic|journalctl --rotate}} を実行することで実行できます。{{ic|--rotate}} 引数を 1 つ以上のバキューム基準引数と一緒に指定して、ローテーションを実行し、単一のコマンドでファイルをトリミングすることもできます。
 詳しくは {{man|1|journalctl}} を見て下さい。
@@ 174行目: / 177行目: @@
 == 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]] を見て下さい。
@@ 183行目: / 186行目: @@
 [[systemd#ユニットファイルの編集|ドロップインディレクトリ]] {{ic|/etc/systemd/journald.conf.d}} を作成して、ディレクトリの中に {{ic|fw-tty12.conf}} ファイルを作成してください:
 {{hc|1=/etc/systemd/journald.conf.d/fw-tty12.conf|2=
 [Journal]
@@ 190行目: / 194行目: @@
 }}
-次を実行して journald を再起動してください:
+次に {{ic|systemd-journald.service}} を [[再起動]] して下さい。
- # systemctl restart systemd-journald
+{{Note|[https://github.com/systemd/systemd/issues/5129 設計上], カーネルのリングログメッセージは転送されません。}}
 == 別のジャーナルを指定して表示 ==
@@ 202行目: / 207行目: @@
 デフォルトでは、一般ユーザは自分のユーザ単位のジャーナルにしかアクセスできません。一般ユーザーとしてシステムジャーナルの読み込みアクセスを許可するには、そのユーザーを {{ic|systemd-journal}} に追加してください。[[ユーザーとグループ#グループ管理|ユーザーグループ]] {{ic|adm}} および {{ic|wheel}} グループのメンバにも読み込み権限が与えられます。
-See {{man|1|journalctl|DESCRIPTION}} and [[Users and groups#User groups]] for more information.
+詳しくは、{{man|1|journalctl|DESCRIPTION}} と [[ユーザーとグループ#ユーザーグループ]]を参照してください。