我在 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 镜像的问题，我已经向他们开了一张支持票。同时，我也在继续寻找这个问题的原因。
我该如何调试这个？什么可能导致这种情况？我可以做什么来解决这个问题？
答案1
出现此行为的原因是计算机标识符/etc/machine-id在每次重新启动时都会发生变化。这将在 下启动一个新的日志记录目录/var/log/journal。可以使用以下命令查看旧日志：
journalctl --merge
我仍在调查机器 ID 更改的原因。 Linode 支持人员已意识到该问题。当我了解更多时，我会更新这个答案。
/etc/machine-id更新——问题的根本原因很简单，Linode 将其文件系统映像中的内容清零。结果是以下事件链：
- 内核以只读方式加载并挂载根文件系统
- 从初始 ramdisk 运行的 systemd 尝试从根文件系统读取
/etc/machine-id（该文件存在但内容为零） - systemd 无法读取机器标识符，但也无法写入新标识符，因为根文件系统是以只读方式挂载的
- systemd 安装
tmpfs在/etc/machine-id（是的，显然你可以将文件系统挂载到文件上） - 系统调用systemd-机器-id-设置它生成一个随机机器 ID 并将其存储在现在易失的
/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 上修复该问题所采取的步骤：
cp /etc/machine-id /etc/machine-id.copy，然后关闭系统电源- 在 Linode Manager 中，转到“救援”选项卡并启动至救援模式
- 通过Lish控制台访问系统
- 挂载根文件系统：
mount /dev/xvda /mnt - 将步骤 1 中创建的副本移至真实机器 ID：
mv /etc/machine-id.copy /etc/machine-id - 重启
这就是启动时缺少机器 ID 的后果。我希望这对将来的路人有所帮助。
答案2
其他选项是通过 uboot 中的内核参数配置 systemd：
setenv bootargs 'systemd.machine_id=fce88f888f3e4a3d811ab2cd1c9b7cbe'