在systemd-journal-flush.service询问期刊守护进程，清除存储在/运行/日志/日记到在/ var /日志/日志的任何日志数据，如果persistent存储已启用。如果您（已经）有巨大的日志文件，这将导致启动速度变慢。此外，磁盘（带有/var/log）必须以可写方式安装才能这样做。

总结一下：在启动过程中检查的大量旧日志文件和新日志数据的附加导致启动时间变慢。

检查 journalctl 日志大小类型

为了获取flush处理的时间和磁盘空间信息，输入以下命令

相应的输出看起来像

那么有可能不是所有的日志数据都写入磁盘；调试启动故障时很烦人。Journald 是systemdlinux 中的一项基本服务，许多其他服务都依赖于它。

验证日志文件的内部一致性：

请注意，每个期刊都会显示PASS。

从 journalctl -h

--vacuum-size=BYTES 将磁盘使用量减少到指定大小以下 --vacuum-files=INT 只保留指定数量的日志文件 --vacuum-time=TIME 删除早于指定时间的日志文件

因此做一个

首先检查您的存储类型

从 man journald.conf

存储=

控制存储日志数据的位置。“volatile”、“persistent”、“auto”和“none”之一。

如果为“ volatile ”，日志日志数据将仅存储在内存中，即低于 /run/log/journal 层次结构（如果需要创建）。

如果“持久”，数据将优先存储在磁盘上，即低于 /var/log/journal 层次结构（如果需要创建），并回退到 /run/log/journal（如果需要创建），在早期启动，如果磁盘不可写。

“ auto ”类似于“persistent”，但如果需要，不会创建目录/var/log/journal，因此它的存在控制了日志数据的去向。

“ none ”关闭所有存储，所有接收到的日志数据都将被删除。然而，转发到其他目标，例如控制台、内核日志缓冲区或系统日志套接字仍然可以工作。默认为“自动”。

编辑文件

在日记部分取消注释并更改：

我建议将SystemMaxFileSize键的大小限制为 20MB -->

最后，如果您的 Ubuntu 没有在重要服务器上运行，我建议将数据存储更改为 volatile：

如果您在调试模式下运行引导并跟踪系统调用 (strace)，您可能会发现刷新写入的 I/O 性能非常差。就我而言，不清楚原因。也许一些内核消息垃圾邮件日志文件（请注意，在 10000 条消息后，该单元默认被阻止，但 journald 必须管理这一点，这可能会导致性能不佳）。在这种情况下，跳过消息并搜索错误，这些错误不一定标记为错误。

和

该--output short-monotonic标志打印与默认 utc 时间相反的时间步长。

最后删除旧的日志文件

保存并重新启动。