Ubuntu 16.04+の再起動後に以前のブートログを見つける方法
私の質問は、以前のシステムブート試行からブートログを見つけるにはどうすればいいですか？
今日、最初にPCの電源を入れたとき、Ubuntuロゴで起動プロセスが停止しました。 Esc 私はいくつかのカーネルエラーを含むいくつかの行を見て、下部で再起動が必要なので、 Ctrl+ALt+Del そして、次のブートは問題なく正常に進みました。
最初の起動に失敗したときに表示された画面からメッセージを見つけることができません。携帯電話で写真を撮る必要がありますか？
/var/log/bootはありますが空です。 kern.log および syslog を検索し、errorのような今日の日付で記憶している文字列を探しましたが、以前のブート画面で見ました。
$ journalctl -b -1はブート中にカーネルメッセージのみを表示します。他の場所でも見つけることができます。これらはブート中に画面に表示されたものではなく、journalctlは役に立たないため、ブート時に画面に表示されるメッセージを探しています。
今のところ、唯一のオプションは、紙にメッセージを書く写真を撮ることです。
文書化されていない機能であるバグとして報告
これについて報告されたバグレポートがあります topic 。 rsyslogはすでに/var/log/syslogおよびsyslog.1、.2.gz、.3.gz... syslog.7.gzに複数のブートジャーナルを保持しているため、開発者は余分なjournalctlログはディスク容量を浪費します。
バグレポートには、2018年1月3日と記載されており、新規インストールではrsyslogがデフォルトではなくなり、journalctlは複数のブートデータログを保持します。
Ubuntuを再インストールせずに複数のブートログを作成する
私たちのほとんどは新しいインストールを行わないので、複数のjournalctlブートログを有効にします。
$ Sudo mkdir -p /var/log/journal
$ Sudo systemd-tmpfiles --create --prefix /var/log/journal
Cannot set file attribute for '/var/log/journal', value=0x00800000, mask=0x00800000: Operation not supported
これによると github report 警告メッセージ "ファイル属性を設定できません"は無視できます。
オプションの永続ストレージ設定
以前のブートロギングを何ヶ月も使用した後、 別のオプションを発見しました/etc/systemd/journald.confで設定できます：
ストレージ=
ジャーナルデータを保存する場所を制御します。 「volatile」、「persistent」、「auto」、および「none」のいずれか。 「揮発性」の場合、ジャーナルログデータはメモリにのみ、つまり/ run/log/journal階層の下に保存されます（必要に応じて作成されます）。 「永続的」である場合、データはできればディスク上、つまり、必要に応じて作成される
/var/log/journal階層の下に格納され、初期ブート時に/run/log/journal（必要に応じて作成）にフォールバックされますまた、ディスクが書き込み可能でない場合。 「auto」は「persistent」に似ていますが、ディレクトリ/var/log/journalは必要に応じて作成されないため、その存在によりログデータの保存先が制御されます。 「none」はすべてのストレージをオフにし、受信したすべてのログデータはドロップされます。ただし、コンソール、カーネルログバッファー、syslogソケットなどの他のターゲットへの転送は引き続き機能します。デフォルトは「auto」です。
一言で言えば、コメントを削除し、次のように行を修正します。
Storage=persistent
以前のブートのリストを表示する
$ journalctl --list-boots
-15 58a9e56135564cd8a52d547b19e76bf5 Fri 2018-02-02 18:34:35 MST—Fri 2018-02-02 23:07:14 M
-14 3514e056440341b1b6e5f03d109681bc Sat 2018-02-03 06:05:12 MST—Sat 2018-02-03 08:07:44 M
-13 0d1a32dc275348589f5ecdc72180c018 Sat 2018-02-03 08:08:05 MST—Sat 2018-02-03 08:08:34 M
-12 74159b593f3a401589ee6bd78e31684b Sat 2018-02-03 08:08:51 MST—Sun 2018-02-04 08:32:09 M
-11 4b394a9aad584ab2bfabe3b77eeed78f Sun 2018-02-04 08:32:26 MST—Mon 2018-02-05 16:54:02 M
-10 8e461ed2593c4fd896ca3b71eb3c0fba Mon 2018-02-05 16:54:34 MST—Tue 2018-02-06 03:54:30 M
-9 ec7ba0e4dfe241c0b9c978d278fcca6d Tue 2018-02-06 03:54:47 MST—Tue 2018-02-06 16:25:02 M
-8 b5c110267c214c38b63d0a367197d118 Tue 2018-02-06 16:25:19 MST—Thu 2018-02-08 16:49:03 M
-7 75c3b117ac6a4de984dc3ced15edb7f8 Thu 2018-02-08 16:49:22 MST—Fri 2018-02-09 03:51:09 M
-6 7338bd1007bc42dda5c8667eeefe1a59 Fri 2018-02-09 03:51:26 MST—Fri 2018-02-09 16:55:52 M
-5 4b6cd0121327454ca3db035c7ed42df6 Fri 2018-02-09 16:56:09 MST—Sat 2018-02-10 07:55:14 M
-4 0d56207f9ec0405ca3a3fd638334de2f Sat 2018-02-10 07:55:32 MST—Mon 2018-02-12 22:16:05 M
-3 0f230cc546fd4aec8f5233e0074ab3e1 Tue 2018-02-13 03:57:20 MST—Wed 2018-02-14 22:58:56 M
-2 c0d2c0141dd840cbab75d3c2254f8781 Wed 2018-02-14 22:59:13 MST—Sat 2018-02-17 22:46:14 M
-1 aafb2573a6374e019a7165cb8eee74a0 Sun 2018-02-18 06:02:03 MST—Mon 2018-02-19 04:16:36 M
0 8462f1969c6f4d61973e7e245014b846 Mon 2018-02-19 04:16:53 MST—Tue 2018-02-20 18:51:42 M
最後の起動ログを表示する
$ journalctl -b-1
-- Logs begin at Fri 2018-02-02 18:34:35 MST, end at Thu 2018-03-01 16:43:25 MST. --
Feb 28 20:03:15 alien systemd-journald[290]: Runtime journal (/run/log/journal/) is 8.0M,
Feb 28 20:03:15 alien kernel: Linux version 4.14.23-041423-generic (kernel@kathleen) (gcc
Feb 28 20:03:15 alien kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-4.14.23-041423-generi
Feb 28 20:03:15 alien kernel: KERNEL supported cpus:
Feb 28 20:03:15 alien kernel: Intel GenuineIntel
Feb 28 20:03:15 alien kernel: AMD AuthenticAMD
Feb 28 20:03:15 alien kernel: Centaur CentaurHauls
Feb 28 20:03:15 alien kernel: x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point
Feb 28 20:03:15 alien kernel: x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
Feb 28 20:03:15 alien kernel: x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
Feb 28 20:03:15 alien kernel: x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registe
Feb 28 20:03:15 alien kernel: x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR'
Feb 28 20:03:15 alien kernel: x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256
Feb 28 20:03:15 alien kernel: x86/fpu: xstate_offset[3]: 832, xstate_sizes[3]: 64
Feb 28 20:03:15 alien kernel: x86/fpu: xstate_offset[4]: 896, xstate_sizes[4]: 64
Feb 28 20:03:15 alien kernel: x86/fpu: Enabled xstate features 0x1f, context size is 960 b
Feb 28 20:03:15 alien kernel: e820: BIOS-provided physical RAM map:
Feb 28 20:03:15 alien kernel: BIOS-e820: [mem 0x0000000000000000-0x0000000000057fff] usabl
lines 1-19
パラメーター-b-1に細心の注意を払ってください。これは、他の参照とは異なる場合があります。 manページ から：
-b [ID][±offset], --boot=[ID][±offset]特定のブートからのメッセージを表示します。これにより、「_ BOOT_ID =」に一致するものが追加されます。
引数は空でもかまいません。その場合、現在のブートのログが表示されます。
ブートIDが省略された場合、正のオフセットはジャーナルの先頭から始まるブートを検索し、ゼロ以下のオフセットはジャーナルの末尾から始まるブートを検索します。したがって、1はジャーナル内で時系列に最初に見つかったブートを意味し、2は2番目のブートを意味します。一方、-0は最後のブート、-1は最後の前のブートなどです。空のオフセットは、現在のブートが最後のブートではない場合を除いて-0を指定するのと同じです（たとえば、-directoryが別のマシンからのログを見るために指定されたため）。
その後、たまにcronまたは timers で 古いログ をクリーニングできます：
journalctl --vacuum-time=2d # keep last two days or
journalctl --vacuum-size=300M # keep last 300MB
私は同じ問題を抱えていたが、明らかに#ubuntu ircチャンネルで答えを見つけた。
なんらかの理由で、systemd-journalにグループ/var/log/journalでアクセス可能なフォルダーがありませんでした。
フォルダーを追加した後、$ journalctl -b1を介して以前のブートのログを見ることができました
Systemd-journaldのmanページから、ここで一番上の答えから解決策を達成するための手順：
mkdir -p /var/log/journal
systemd-tmpfiles --create --prefix /var/log/journal
systemctl restart systemd-journald
私はsuとしてこれをしました
答えはman journald.conf、特にオプションStorage=にあります。
ジャーナルデータを保存する場所を制御します。 「volatile」、「persistent」、「auto」、および「none」のいずれか。 [...]「auto」は「persistent」に似ていますが、ディレクトリ/ var/log/journalは必要に応じて作成されないため、その存在によりログデータの行き先が制御されます。 [...]デフォルトは「auto」です。
ログのローテーションや、古いsyslogデーモンで一般的だった同様の手法は必要ないことに注意してください。ジャーナルファイルはデフォルトで特定のサイズに拡大するように設定されており、ジャーナルファイルが大きくなりすぎると古いログエントリは自動的に削除されます。
私のシステムでは、このサイズは現在120MBに設定されていますが、systemd-journald.serviceユニットの/etc/systemd/journald.confで調整できます。
journalctl -bX（xは参照するブート）を使用します。したがって、-b0は実際のブートであり、-b-1はブート前です（これは/var/log/journalフォルダーに属している場合のみ機能しますグループ「systemd-journal」の存在）。カントは、あなたがどこまで正確に行けるかを教えてくれますが、この2つは確かです。
利用可能なリスト で起動
journalctl --list-boots