web-dev-qa-db-ja.com

16.04以降、ブートロギングはありませんか？

/var/log/boot.logファイルの日付は2016-04-22で、前回15.10で起動したことに気付きました。 Xenial boot.logファイルはどこにありますか？

boot16.04loglogging
23
jasmines

journalctlを使用

journaldにはすべてのログが含まれているため、適切なフィルターで journalctl コマンドを使用できます。 initシステムからのメッセージを含むboot.logの場合、次のようにできます。

journalctl -b0 SYSLOG_PID=1
  • -b0は現在のブートからのメッセージ、-b1は前回のブートからのメッセージなどを表示します。 -bオプションを使用しない場合、journalctlはログの先頭からメッセージを表示します。
  • SYSLOG_PIDは、PID 1（別名init）からのメッセージをフィルターします。

または：

journalctl -b0 --system _COMM=systemd
  • _COMM=systemdは、systemdコマンドからのメッセージを探します。 systemdはinitなので、これが興味のあるものです。
  • --systemは、ユーザーセッションログではなくシステムログからメッセージをフィルターします。

例：

muru@muru-vm:~$ journalctl -b0 SYSLOG_PID=1
Apr 30 12:29:18 muru-vm systemd[1]: systemd 229 running in system mode. (+PA
Apr 30 12:29:18 muru-vm systemd[1]: Detected virtualization qemu.
Apr 30 12:29:18 muru-vm systemd[1]: Detected architecture x86-64.
Apr 30 12:29:18 muru-vm systemd[1]: Set hostname to <muru-vm>.
Apr 30 12:29:18 muru-vm systemd[1]: Initializing machine ID from random gene
Apr 30 12:29:18 muru-vm systemd[1]: Installed transient /etc/machine-id file
Apr 30 12:29:18 muru-vm systemd[1]: Set up automount Arbitrary Executable Fi
Apr 30 12:29:18 muru-vm systemd[1]: Listening on fsck to fsckd communication
Apr 30 12:29:18 muru-vm systemd[1]: Reached target User and Group Name Looku
Apr 30 12:29:18 muru-vm systemd[1]: Listening on udev Kernel Socket.
Apr 30 12:29:18 muru-vm systemd[1]: Started Forward Password Requests to Wal
Apr 30 12:29:18 muru-vm systemd[1]: Listening on /dev/initctl Compatibility 
Apr 30 12:29:18 muru-vm systemd[1]: Listening on Journal Socket.
Apr 30 12:29:18 muru-vm systemd[1]: Created slice User and Session Slice.
Apr 30 12:29:18 muru-vm systemd[1]: Created slice System Slice.
Apr 30 12:29:18 muru-vm systemd[1]: Starting Braille Device Support...
Apr 30 12:29:18 muru-vm systemd[1]: Mounting POSIX Message Queue File System
Apr 30 12:29:18 muru-vm systemd[1]: Mounting Debug File System...
Apr 30 12:29:18 muru-vm systemd[1]: Mounting Huge Pages File System...
Apr 30 12:29:18 muru-vm systemd[1]: Starting Load Kernel Modules...
Apr 30 12:29:18 muru-vm systemd[1]: Starting Uncomplicated firewall...
Apr 30 12:29:18 muru-vm systemd[1]: Starting Create list of required static 
lines 1-23

journalctlはデフォルトでページャーでログを開くため、lessにパイプする必要はありません。

永続的なロギング

Ubuntuはデフォルトで、永続的なjournaldログを有効にしません。 @ Auspexによるコメント のおかげで、次のいずれかを行う必要があります。

  1. /etc/systemd/journald.confを編集して、以下を含めます。

    Storage=persistent

  2. /var/log/journalディレクトリを手動で作成します。

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

関連する：

31
muru

私はいくつかのバグレポートを調べていて、このレポートに気付きました： https://bugs.launchpad.net/ubuntu/+source/ubuntu-gnome-default-settings/+bug/1536771 そのプリマスは実際にboot.logに書き込みます。

https://launchpadlibrarian.net/257898272/plymouth-debug.log を見て、ブラウザで「boot.log」を検索すると、次の行が表示されます。

[main.c:821] on_system_initialized:system now initialized, opening log 
[main.c:742] get_log_file_for_state:returning log file '/var/log/boot.log'
[main.c:805] prepare_logging:opening log '/var/log/boot.log'

私はプリマスの内部がどのように機能するのか理解していませんが、ログイン画面の前に表示されるスプラッシュ画面を担当しているため、ログイン画面に到達する前にスプラッシュ画面（黒い画面）がない場合にのみ想定できます、ファイルは変更されません。ログイン画面の前にスプラッシュ画面が表示されている場合、起動プロセスの出力はboot.logファイルにリダイレクトされます。

3
octoquad

Ubuntu 16.04では、boot.logファイルは here でわかるように/var/logフォルダーにあります。ブートログファイルは今日（2016-04-29）のものです。 Ubuntu 16.04をインストールしたとき、またはオペレーティングシステムをUbuntu 15.10からUbuntu 16.04 LTSにアップグレードしたときに何か問題が発生した可能性があります。

または、包括的なkern.logファイルから一般的なブート動作を調べることができます。別の可能な代替手段は、手動でsyslog daemonを構成してブートログファイルを生成することです。正確にこれを行う方法： Linuxログを表示および構成する方法

追加情報 ：

2つの異なるマシンでのブートロギングの動作を調査しました。 UEFIベースのBIOSを搭載したコンピューターにはboot.logファイルが存在しますが、レガシーベースのBIOSを搭載したコンピューターにはまったく存在しないようです。したがって、システムがレガシーBIOS（MBR/msdos）モードでインストールされている場合、これはboot.logファイルの日付が2016-04-22である理由であり、Ubuntu 15.10の残り物です。

更新情報2016-05-02：

ブートロギングファイルの動作を調査し続け、boot.logファイルがUEFIベースのマシンにまだ存在することを観察しましたが、数日後、ファイルは空になります。ブートプロセス中に何が起こるかを確認しようとした別の方法は、 BootChart をインストールすることでしたが、システムの再起動後にbootchart.pngフォルダーが/var/logフォルダーに存在しませんでした.. 。予想される/var/log/bootchartファイルも含まれていない空のbootchart.pngフォルダーのみがありました。

更新された情報2016-05-04：

今日、boot.logファイルは再び「機能」を持っているようで、ブートプロセスからの部分的な情報で満たされています。これはランダムに変化する振る舞いのようで、Ask Ubuntuではここでは解決できないと思うので、これを解決するにはLaunchpadにバグレポートを提出することを検討する必要があります！

結論-Ubuntu 16.04でのboot.logファイルの動作に関する1週間の調査の後：/var/log/boot.log anyについて心配する必要はありませんより長く、代わりにjournalctlに慣れるだけです。

2
cl-netbox