logo标签列表

自16.04版本以来，不再有启动日志记录了吗？

boot16.04loglogging
我注意到我的/var/log/boot.log文件的日期是2016-04-22，上次我是在15.10版本启动的。Xenial版本的boot.log文件在哪里？
真正的问题不是登录，而是查看引导速度慢的原因。现在你可以使用 systemd-analyze blame 和/或 systemd-analyze critical-chain。我发现这比翻找日志文件来找出问题原因更容易。 - oldfred
所以，你们中没有人能解释为什么2016-04-22的boot.log被保留下来吗...？真的吗？ - jasmines
1@jasmines：很遗憾我们无法告诉您为什么会发生这种情况...我们不是开发人员...我已经更新了我的答案，加入了一些今天的新信息...您应该考虑在Launchpad上提交一个错误报告。:) - cl-netbox
@jasmines 显而易见吧？那是你上次使用15.10的日期。16.04不再使用boot.log了。因此，boot.log最后更新的日期就是你使用15.10的最后日期。 - muru
@muru为什么你说16.04不使用boot.log？我的系统每次启动时该文件还是会更新的（我使用的是16.04，MBR引导方式，从15.10升级而来）。http://pastebin.ubuntu.com/16236745/ - dadexix86
@dadexix86 进行全新安装并亲自体验。 - muru
@muru 但问题不是关于干净安装...问题是关于升级的16.04，在这种情况下，该文件应在每次启动时更新。 - dadexix86
@dadexix86 为什么？你怎么知道每个从15.10升级到16.04的实例都应该更新boot.log？ - muru
@muru 不好意思，我的英文不太好。并非每个系统都是如此。但人们会期望有一定的一致性。所以，在我的系统上它会更新，在cl-netbox的系统上也会更新，OP问道：“为什么在我的系统上没有更新呢？” - dadexix86
我会认为这是一个错误。自从15.04版本开始使用systemd，journald也至少同样长时间被使用。所以，拥有一个boot.log文件实际上是没有意义的。我很惊讶15.10版本甚至还有一个boot.log文件；任何它可能有的用途都可以通过使用适当选项的journalctl命令来完成。你的英语没问题；楼主可能需要更加礼貌一些。 - muru
让我们在聊天中继续这个讨论。 - muru
3journalctl在启动过程中没有显示我在闪屏中看到的内容，而我需要这个信息。 - jasmines
2那个看起来很漂亮的带着"[FAILED]"红色标志的日志，你又拿到了吗？我的文件是2017年的... - Aquarius Power
3个回答

使用 journalctl

由于 journald 包含所有日志，您可以使用适当的过滤器来使用 journalctl 命令。对于以前包含 init 系统消息的 boot.log，您可以执行以下操作：

journalctl -b0 SYSLOG_PID=1
  • -b0 显示当前引导的消息，-b1 显示前一个引导的消息，以此类推。如果不使用 -b 选项，journalctl 将显示日志从开头开始的消息。
  • SYSLOG_PID 过滤来自进程 ID 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的评论，您需要执行以下操作之一：

编辑/etc/systemd/journald.conf文件，添加以下内容： Storage=persistent
手动创建/var/log/journal目录： mkdir /var/log/journal systemd-tmpfiles --create --prefix /var/log/journal systemctl restart systemd-journald

相关：

为什么boot.log保存在2016-04-22的问题呢？ - jasmines
@jasmines 也许他们决定在16.04版本中停止使用boot.log。 - muru
3journalctl在启动过程中没有显示我在闪屏中看到的内容，而我需要这个信息。 - jasmines
@jasmines，你在启动过程中看到了什么？完整的journalctl输出肯定会包含它。 - muru
1我正在查看之前在boot.log中记录的内容，格式如下：[ OK ] 启动自我监测和报告技术（SMART）守护程序。 挂载任意可执行文件格式文件系统... [ OK ] 启动登录服务。 正在启动LSB：启动NTP守护进程... [ OK ] 启动Avahi mDNS/DNS-SD堆栈。 [ OK ] 启动使远程CUPS打印机本地化。 [ OK ] 启动调制解调器管理器。 [ OK ] 启动网络管理器。 正在启动网络管理器等待在线... [ OK ] 达到目标网络。 [ OK ] 启动账户服务。以此类推... - jasmines
1保持你的语气和措辞友善。我们有一个“友善行为”政策，请遵守。 - Seth
1journalctl -bX 对于这个问题是无用的，它不包含在启动过程中真正出现在屏幕上的消息，只有 boot.log 包含，并且在 16.04 上只能有时候起作用，唯一的方法就是拍照或者把它写下来。我也有同样的问题。 - Mike
@Mike 那是什么问题？ journalctl 包含了所有的日志，只需要应用正确的过滤器。如果不知道你要找什么，我无法帮助你。 - muru
1正如jasmines已经提到的，以[ OK ]开头的引导消息...这些内容在boot.log中，但在journalctl中有所不同，即使使用像-b0 SYSLOG_PID=1或-b1用于上一次启动的标志，也不是所有东西都在那里，尤其是我遇到的错误，我无法在日志中找到任何地方。大部分的消息都在那里，我不知道如何重现这个问题，所以无法提供帮助，但它是与内核相关的错误，却无法找到，问题现在消失了，但我仍然不明白为什么引导消息没有像它们在屏幕上显示的那样被记录下来。 - Mike
@Mike，以OK开头的东西并不是错误。所以，在这里你应该关注你看到的错误。这才是你应该专注的地方，而不是像jasmines那样关注boot.log的格式。 - muru
1有错误的那一行没有“OK”，只是我在描述屏幕上大部分内容，现在我知道我应该拍照了，很难证明/找到不存在的东西，电脑在启动时冻结，并出现与内核相关的错误，但内核日志或journalctl中没有这个错误，我相信journalctl是一个很好的工具，但很难解释，因为boot.log为空，而journalctl、dmesg、syslog或kernel.log中也没有类似的错误信息可供查看，如何调试？升级内核后问题消失了，但问题是为什么消息没有记录在boot.log中？ - Mike
1我在Ubuntu 16.04（从14.04升级而来）也遇到了这个问题。'journalctl'的输出中没有有用的信息，'/forcefsck'已被删除，但是'dumpe2fs -h /dev/sda1'显示'上次检查'未更新。看起来fsck没有运行？ - Chris Good
1这是一个很好的答案，除了一件事。在新安装的Ubuntu上，默认情况下是没有启用持久日志的，至少在LTS 16.04.1版本中是如此（也就是说，如果你没有/var/log/journal/目录，那么你就没有持久化日志记录）。你可以通过修改/etc/journald.conf文件来包含Storage=persistent，或者以root:systemd-journal用户和drwxr-sr-x+权限创建/var/log/journal/目录。 - Auspex
1有没有办法只过滤出那些以"[FAILED]"开头的红色消息，因为它们显示得太快，我们甚至来不及读完？ - Aquarius Power
这些命令并不能提供与 boot.log 内容相等的信息。boot.log 提供的远不止如此！ - Laurent Simon
我正在查看一些错误报告，并注意到其中一个：https://bugs.launchpad.net/ubuntu/+source/ubuntu-gnome-default-settings/+bug/1536771，发现Plymouth实际上是写入了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'

我对Plymouth的内部工作原理一无所知，但由于它负责在登录界面之前显示启动画面，我只能假设如果在进入登录界面之前没有启动画面（黑屏），那么文件就没有被修改。如果你在登录界面之前有一个启动画面显示，那么启动过程的输出会被重定向到boot.log文件中。
很遗憾，我有启动画面，但没有启动日志... - jasmines
3我确认，在/etc/default/grub中配置GRUB_CMDLINE_LINUX_DEFAULT=""时，不会写入boot.log。当使用GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"时，boot.log又会被写入。我使用的是Ubuntu 19.04版本。 - Adrian
在Ubuntu 16.04中，boot.log文件仍然位于/var/log文件夹中，你可以在这里看到here。引导日志文件是今天的（2016年4月29日）。也许在安装Ubuntu 16.04时出了问题，或者将操作系统从Ubuntu 15.10升级到Ubuntu 16.04 LTS时出了问题。
另一种选择是从综合的kern.log文件中检查一般的引导行为。另一个可能的选择是手动配置syslog守护进程以生成引导日志文件，这里有一个教程告诉你如何做：How To View and Configure Linux Logs 附加信息：

我调查了两台不同机器的启动日志行为。在一个使用UEFI基于BIOS的计算机上，存在着boot.log文件 - 但是在一个使用传统基于BIOS的计算机上，似乎根本不存在这个文件。所以如果系统是以传统BIOS（MBR/msdos）模式安装的话，这可能解释了为什么你的boot.log文件的日期是2016-04-22，它是Ubuntu 15.10的残留文件。

更新信息 2016-05-02 ：

我继续调查启动日志文件的行为，并观察到在基于UEFI的机器上boot.log文件仍然存在，但是几天前开始该文件变为空白。我尝试了另一种方法来观察启动过程中发生的情况，即安装BootChart，但在系统重启后预期在/var/log文件夹中并不存在bootchart.png ... 只有一个空的/var/log/bootchart文件夹，也没有预期的bootchart.png文件。

更新信息 2016-05-04 ：

今天的`boot.log`文件似乎又有了一些“功能”，它充满了来自启动过程的部分信息。这似乎是一个随机变化的行为，在Ask Ubuntu上无法解决-所以你应该考虑在Launchpad上提交一个错误报告来解决这个问题！
结论 - 在对Ubuntu 16.04中的`boot.log`文件行为进行了一周的调查后：你不再需要担心`/var/log/boot.log`，而是要适应使用`journalctl`。
不要觉得出了什么问题，无论如何，如果你能提供关于如何解决我的问题的建议，我仍然愿意接受你的答案。 - jasmines
尝试按照教程手动配置syslog守护进程以生成启动日志文件。我在/etc/rsyslog.d/50-default.conf文件中添加了# Save boot messages also to boot.log
local7.* /var/log/boot.log
但是没有成功，/var/log/boot.log仍然是2016-04-22。 - jasmines
在我刚安装的Ubuntu 16.04上，我还发现boot.log文件不在它通常的位置。 - user364819
@ParanoidPanda ：在提到的这两台机器上，我进行了一次干净/全新安装（而不是升级）Ubuntu 16.04 LTS - 看起来以前的启动日志记录方式不再得到适当支持了。 :) - cl-netbox
@cl-netbox：也许你应该向负责生成日志的程序开发人员咨询一下，因为可能只是一个错误。 - user364819
关于为什么boot.log文件保留在2016-04-22的问题，有什么答案吗？ - jasmines
我的工作正常，最后更新时间是今天。我使用的是MBR系统，从15.10升级而来。@jasmines，你的/var/log/boot.log还保留着吗？ - dadexix86
3journalctl没有显示我在启动过程中看到的闪屏内容，我需要它。 - jasmines