为什么我的 systemd 日志在重新启动后不持久？

Question

我在 Linode 实例上遇到了新的 Fedora 21 映像的一个非常奇怪的问题。我无法在 Linode 之外复制它。问题是我的 systemd 日志在重新启动后不是持久的。根据文档：

默认情况下，日志将日志数据存储在 /run/log/journal/ 中。由于 /run/ 是易失性的，重启时日志数据会丢失。为了使数据持久化，创建 /var/log/journal/ 就足够了，然后 systemd-journald 将存储数据。

我已经检查过 /var/log/journal 是否存在，并且我还在Storage=persistent/etc/systemd/journald.conf 中进行了设置。日志目录包含一堆数据：

$ du -sh /var/log/journal/
89M /var/log/journal/

但是，日志仅包含自上次系统重新启动以来的日志条目：

$ journalctl --list-boots
 0 9f6a5a789dd64ec0b067140905e6da86 Thu 2015-03-19 15:08:48 GMT—Thu 2015-03-19 22:14:37 GMT

即使我journalctl --flush在重新启动之前，日志也丢失了。我怀疑这是 Linode 的 Fedora 21 映像的问题，我已经向他们开了一个支持票。同时，我继续寻找这个问题的原因。

我该如何调试？什么可能导致这种情况？我能做些什么来解决这个问题？

Answer 1

这种行为的原因是机器标识符在/etc/machine-id每次重新启动时都会发生变化。这将在/var/log/journal. 可以使用以下命令查看旧日志：

journalctl --merge

我仍在调查更改机器 ID 的原因。Linode 支持人员已经意识到这个问题。当我知道更多时，我会更新这个答案。

更新 - 问题的根本原因很简单，Linode 将/etc/machine-id其文件系统映像中的内容归零。结果是以下事件链：

内核以只读方式加载和挂载根文件系统
systemd，从初始 ramdisk 运行，尝试/etc/machine-id从根文件系统读取（文件存在但内容为零）
systemd 不能读取机器标识符，但也不能写入新的，因为根文件系统是只读挂载的
systemd坐骑tmpfs上/etc/machine-id（是的，显然你可以挂载文件系统到一个文件）
systemd 调用systemd-machine-id-setup生成随机机器 ID 并将其存储在 now-volatile/etc/machine-id
系统使用易失机器标识符启动

您可以通过查看以下输出来检查您的系统是否具有易失性而非永久机器 ID mount：

$ mount | grep machine-id
tmpfs on /etc/machine-id type tmpfs (ro,mode=755)

这个问题很容易解决：只需将一个持久的机器 ID 写入真实的 /etc/machine-id. 然而，这说起来容易做起来难，因为您无法tmpfs从/etc/machine-id正在运行的系统上卸载。这些是我在 Linode 上修复它的步骤：

这就是启动时缺少机器 ID 的后果。我希望这对未来的随机路人有所帮助。

您可以使用 / 的绑定挂载来更改 /etc/machine-id，而无需救援/重新启动：```mkdir /tmp/mnt; 挂载 --bind //tmp/mnt; cp -a /etc/machine-id /tmp/mnt/etc/; 卸载/tmp/mnt``` (7认同)