Ubuntu 16.04+の再起動後に以前のブートログを見つける方法


20

私の質問は、以前のシステム起動試行から起動ログを見つけるにはどうすればよいですか?

今日、最初にPCの電源を入れたとき、Ubuntuロゴでブートプロセスが停止し、押したときにEscいくつかのカーネルエラーを含む行が表示され、下部で再起動が必要になったため、Ctrl+ ALt+ を押してDel、次のブートは問題なく正常に実行されました。

最初の起動に失敗したときに見た画面からメッセージを見つけることができません。携帯電話で写真を撮る必要がありますか?

/var/log/bootそこは空ですが、kern.logsyslogで今日の日付のような文字列を検索しましたerrorが、以前のブート画面で見たものになじみのないものは見つかりませんでした。

$ journalctl -b -1 ブート中にカーネルメッセージのみを提供しますが、他の場所でもそれを見つけることができます。それらはブート中に画面に表示されていたものではなく、journalctlは私にとって役に立たない、ブート時に画面に表示されるメッセージを探しています

今のところ、唯一のオプションは、紙にメッセージを書く写真を撮ることです。

回答:


17

文書化されていない機能であるバグとして報告

このトピックに関して報告されたバグレポートがあります。ので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レポートによると、「ファイル属性を設定できません」という警告メッセージが表示されます。は無視できます。

オプションの永続ストレージ設定

以前のブートロギングを何ヶ月も使用した後、次のように設定できる別のオプション発見しました/etc/systemd/journald.conf以下。

journald.confのmanページから:

ストレージ=

ジャーナルデータを保存する場所を制御します。「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またはタイマーを使用して、古いログを消去できます:

journalctl --vacuum-time=2d  # keep last two days or

journalctl --vacuum-size=300M  # keep last 300MB

systemctl restart systemd-journald またはkillall -USR1 systemd-journaldする必要があります。また、コメントを外してStorage=autoから/etc/systemd/journald.conf
パブロビアンキ

@PabloBianchiコメントありがとうございます。既にマルチブートログを作成しており、300MBから150MB未満に削減する掃除機が毎月のcronジョブとして設定されているため、すべてを削除して最初からやり直して推奨事項をテストする気はありません。とにかく何も影響を与えないように見えるエラーメッセージを他の人が避けるのに役立つことを願っています。
WinEunuuchs2Unix

1
@PabloBianchi "storage = auto"がデフォルトです。ソースから引用された推奨事項が「storage = persistent」であることを示す回答を修正しました。
WinEunuuchs2Unix

9

私は同じ問題を抱えていて、どうやらその答えを見つけました #ubuntu irc-channelで。

なんらかの理由で、フォルダがありませんでした /var/log/journal systemd-journalにグループアクセス可能な。

フォルダを追加した後、以前のブートのログを表示できました $ journalctl -b1


ありがとう、しかし、私はすでにjournalctlを完全に動作させることができましたが、そこにはブートログがありません、それはブート時からのカーネルメッセージだけです、私は他の場所でもそれを見つけることができます 起動中に画面に表示されるメッセージを含むログを見つけることができませんでした。
マイク

10
実際の代替ソリューションはwikiで提供さStorage=persistent/etc/systemd/journald.confていますsystemctl restart systemd-journald。つまり、設定して実行します。
dma_k

1
そう/var/log/journalだね これは新規インストールです。ジャーナルが欠落しているのと同じくらい重要なことは何ですか!!!
-dashesy

私の場合、編集/etc/systemd/journald.conf により以前は存在していなかったが作成され、その中に/var/log/journal/
ブートログ

@ knb、fwiw、systemctl restart systemd-journaldあなたの/ var / log / journalを実際に作成したのは確かだと思う
Auspex

5

systemd-journaldのmanページから、ここで一番上の答えから解決策を達成する手順:

mkdir -p /var/log/journal
systemd-tmpfiles --create --prefix /var/log/journal
systemctl restart systemd-journald

私はsuとしてこれをしました


3

答えはman journald.conf、特にオプションにありますStorage=

ジャーナルデータを保存する場所を制御します。「volatile」、「persistent」、「auto」、および「none」のいずれか。[...]「auto」は「persistent」に似ていますが、ディレクトリ/ var / log / journalは必要に応じて作成されないため、その存在によりログデータの行き先が制御されます。[...]デフォルトは「auto」です。

ログのローテーションや、古いsyslogデーモンで一般的だった同様の手法は必要ないことに注意してください。ジャーナルファイルはデフォルトで特定のサイズに拡大するように設定されており、ジャーナルファイルが大きくなりすぎると古いログエントリは自動的に削除されます。

私のシステムでは、このサイズは現在120MBに設定されていますが/etc/systemd/journald.conf、systemd-journald.serviceユニット用に調整できます。


3

使用journalctl -bXxはあなたが参照ブーツですので、-b0あなたの実際のブートとある-b-1フォルダを持っている場合のみ動作する前に、ブート(/var/log/journalグループに属する「にsystemd-ジャーナル」が存在します)。カントは、あなたがどこまで正確に行けるかを教えてくれますが、この2つは確かです。

使用可能なブートのリスト

journalctl --list-boots

2
-b0は機能しましたが、-b1は私に与えてくれましたSpecifying boot ID has no effect, no persistent journal was found.
マイク

それから、私の推測では、データはその失敗したブートから失われています。一見持ってここに古いログを再活性化するために多くの手間をかけずには不可能である私はちょうど自分自身を発見します。私のシステムで不活性なものをいじるのに約2時間楽しんでいました。
Videonauth

投票するが、誰かがこれを行うための別の方法を追加することを望んでいる、デフォルトの設定では以前のセッションから以前のブートログを見つけることができない場合、それはどのようにブート問題をデバッグしますか?
マイク

1
ここの投稿は、Ubuntu Server 16.04LTS(unix.stackexchange.com/a/345978/77095)のデフォルト設定で機能し、journalctl -o short-precise -k -b -1最後の起動を示しています。
jtlindsey
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.