![DigitalOcean droplet 启动后,journalctl 随机停止工作](https://linux22.com/image/765039/DigitalOcean%20droplet%20%E5%90%AF%E5%8A%A8%E5%90%8E%EF%BC%8Cjournalctl%20%E9%9A%8F%E6%9C%BA%E5%81%9C%E6%AD%A2%E5%B7%A5%E4%BD%9C.png)
我正在使用 DigitalOcean 上的 Packer 制作的自定义映像构建服务器,并且遇到了一个反复出现的问题,即 journalctl 没有任何日志:
# journalctl
No journal files were found.
我构建的镜像有时会出现此问题,有时不会。有时用同一镜像构建的服务器可以运行,而另一台则不行。
我还注意到,如果我快速登录服务器,有时 journalctl 最初可以正常工作,但很快就会中断(<1 分钟后)。
如果我重新启动 journald,那么它就会从那时起正常工作,但我会丢失在此之前的所有日志。
答案1
它不是随机的。“随机性”取决于从构建镜像到启动服务器之间是否已过去 10 分钟 - 这就是为什么有时同一镜像会产生不同的结果。
问题是您没有清除图像中的机器 ID。
DigitalOcean 通过 cloud-init 注入首次启动脚本,以生成新的机器 ID(如果基础映像中有一个)。此脚本用于判断机器 ID 是否已嵌入映像的启发式方法是检查 mtime 是否/etc/machine-id
超过 10 分钟前。
/var/lib/cloud/scripts/per-instance/machine_id.sh
:
# record timestamp on machine-id for testing
# If /etc/machine_id is over 10m old on first-boot, delete it
if [ -f /etc/machine-id ]; then
if [ $DIFF -lt 600 ]; then
exit 0
fi
rm -rf /etc/machine-id
fi
systemd 日志将日志文件存储在磁盘上以机器 ID 命名的目录中,因此更改机器 ID 会导致其失去对这些日志的跟踪。
journalctl
您可以通过从旧目录加载日志来查看机器 ID 更改之前的日志,例如:
journalctl -D /var/log/journal/4ff0f6fdda274a6b9d2b9287b8a15c81
此处的修复方法是清除烘焙图像中的 machine-id。您可以通过删除/var/lib/dbus/machine-id
和来执行此操作/etc/machine-id
,或者您也可以使用 machine-id 脚本包装器-virt-sysprep,这是一个用于将虚拟机准备为映像的有用脚本库。