☰

报告为未记录功能的错误

tag-icon • tag-icon 16.04 boot logs systemd-journald
报告为未记录功能的错误

我的问题是，如何找到上次系统启动尝试的启动日志？

今天，当我第一次打开我的电脑时，启动过程在 Ubuntu 徽标上停止，当我按下时，Esc我看到底部有几行包含一些内核错误和需要重新启动的信息，所以我按下了Ctrl+ ALt+ Del，下一次启动就顺利了。

我无法从第一次启动失败时看到的屏幕上找到消息。我应该拍照并上传到手机吗？

/var/log/boot那里空无一人，我搜索过内核日志和系统日志对于字符串，我记得有今天的日期，error但却没有发现任何与上次启动屏幕上看到的熟悉的内容。

$ journalctl -b -1在启动期间只给我内核消息，我也可以在其他地方找到它们，而且它们不是启动期间出现在屏幕上的内容，journalctl 对我来说没用，我正在寻找启动期间出现在屏幕上的消息。

目前，唯一的选择是拍照或将信息写在纸上。

答案1

报告为未记录功能的错误

有一个关于此的错误报告话题。因为已经在和、、...rsyslog中维护了多个启动日志，开发人员认为保留额外的日志会浪费磁盘空间。/var/log/syslogsyslog.1.2.gz.3.gzsyslog.7.gzjournalctl

错误报告指出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 手册页：

存储=

控制日志数据的存储位置。“volatile”、“persistent”、“auto”和“none”之一。如果为“volatile”，日志数据将仅存储在内存中，即 /run/log/journal 层次结构（如果需要则创建）之下。如果为“persistent”，数据将优先存储在磁盘上，即层次结构/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它与您可能看到的其他参考资料不同。来自手册页：

-b [ID][±offset], --boot=[ID][±offset]

显示特定启动的消息。这将添加“_BOOT_ID=”的匹配项。

该参数可能为空，在这种情况下将显示当前启动的日志。

如果省略启动 ID，则正偏移量将从日志开头开始查找启动，而等于或小于零的偏移量将从日志结尾开始查找启动。因此，1 表示按时间顺序在日志中找到的第一个启动，2 表示第二个启动，依此类推；而 -0 表示最后一个启动，-1 表示倒数第二个启动，依此类推。空偏移量相当于指定 -0，除非当前启动不是最后一个启动（例如，因为指定了 --directory 来查看来自不同机器的日志）。

然后每隔一段时间，cron或计时器你可以清理旧日志：

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

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

答案2

#ubuntu我遇到了同样的问题，显然在irc-channel上找到了答案。

无论出于什么原因，我都缺少了/var/log/journal systemd-journal 可访问的文件夹组。

添加文件夹后，我可以通过以下方式查看以前的启动日志$ journalctl -b1

答案3

使用journalctl -bXx 表示您引用的启动，因此也是-b0您的实际启动和-b-1之前的启动（仅当您拥有/var/log/journal属于组“systemd-journal”的文件夹时才有效）。无法告诉您您到底能走多远，但这两个肯定是。

可用列表靴子

journalctl --list-boots

答案4

答案可以在中找到man journald.conf，特别是选项Storage=：

控制日志数据的存储位置。“挥发性”、“持久性”、“自动”和“无”之一。[...]“自动”类似于“持久性”，但如果需要，则不会创建目录 /var/log/journal，因此它的存在控制着日志数据的存储位置。[...] 默认为“自动”。

请记住，不需要日志轮换或与旧 syslog 守护程序常见的类似技术。日志文件默认配置为增长到一定大小，当日志文件增长过大时，旧日志条目会自动删除。

/etc/systemd/journald.conf在我的系统上，此大小当前配置为 120MB，您可以为 systemd-journald.service 单元进行调整。

相关内容