为什么我的系统日志在重新启动后无法持久保存?


8

我在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映像的问题,我已经与他们一起打开了支持票。同时,我继续寻找导致此问题的原因。

我该如何调试?是什么原因造成的?我该怎么做才能解决此问题?

Answers:


14

出现这种现象的原因是,/etc/machine-id每次重新启动时,计算机标识符都会更改。这将在下启动一个新的日志目录/var/log/journal。可以使用以下命令查看旧日志:

journalctl --merge

我仍在寻找更改机器ID的原因。Linode支持人员已意识到该问题。当我知道更多时,我将更新此答案。


更新-问题的根本原因只是Linode将/etc/machine-id其文件系统映像中的内容清零了。结果是以下事件链:

  1. 内核以只读方式加载和挂载根文件系统
  2. systemd,从初始ramdisk运行,尝试/etc/machine-id从根文件系统读取(该文件存在但内容为零)
  3. systemd无法读取机器标识符,但是也不能写入新的标识符,因为根文件系统是只读安装的
  4. systemd挂载tmpfs/etc/machine-id(是的,显然您可以将文件系统挂载到文件上
  5. systemd调用systemd-machine-id-setup生成一个随机的机器ID并将其存储在now-volatile中/etc/machine-id
  6. 系统使用易失的机器标识符启动

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

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

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

  1. cp /etc/machine-id /etc/machine-id.copy,然后关闭系统电源
  2. 在Linode Manager中,转到选项卡Rescue并启动进入救援模式
  3. 通过Lish控制台访问系统
  4. 挂载根文件系统: mount /dev/xvda /mnt
  5. 将在步骤1中创建的副本移动到真实的机器ID: mv /etc/machine-id.copy /etc/machine-id
  6. 重启

这是引导时缺少机器ID的后果。我希望这会在将来对随机路人有所帮助。


5
您可以使用/的绑定挂载更改/ etc / machine-id,而无需进行抢救/重新引导:mkdir /tmp/mnt; mount --bind / /tmp/mnt; cp -a /etc/machine-id /tmp/mnt/etc/; umount /tmp/mnt
rudimeier 2016年
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.