我今天在玩 BPF 工具（来自 Brendan Gregg 的BPF 书）并运行命令sudo opensnoop-bpfcc -x -U，发现有很多这样的痕迹：
0 403 systemd-journal -1 2 /run/log/journal/5c01742aed6d4d58bed5f1671e612657/system.journal
这是我的主要联想 p72 机器，运行 Ubuntu 20.04……
$ uname -a
Linux 5.4.0-39-generic #43-Ubuntu SMP Fri Jun 19 10:28:31 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
在研究这个问题时，我发现/run/log/journal：
$ ls -al /run/log/journal/
total 0
drwxr-sr-x+ 2 root systemd-journal 40 Jun 28 15:06 .
drwxr-xr-x 3 root root 60 Jun 28 15:06 ..
.../run确实是一个临时文件系统：
$ cat /proc/mounts | grep run
tmpfs /run tmpfs rw,nosuid,nodev,noexec,relatime,size=6554292k,mode=755 0 0
为什么 journald 会尝试访问临时文件系统挂载上不存在的位置的文件？是不是配置有误？即使我编辑/etc/systemd/journald.conf并将配置更改为Storage=parsistent，journald 仍会尝试访问/run/log。唯一正确的位置是/var/log/journal/路径在我的系统中存在的位置，并且它确实会将内容写入该位置。这也发生在下面列出的运行相同操作系统的第二台机器上。
更新 2020-07-24 11:44:27
> grep -v '#' /etc/rsyslog.d/50-default.conf | sed '/^$/d'
auth,authpriv.* /var/log/auth.log
*.*;auth,authpriv.none -/var/log/syslog
kern.* -/var/log/kern.log
mail.* -/var/log/mail.log
mail.err /var/log/mail.err
*.emerg :omusrmsg:*
答案1
这种行为是正常的并且没问题。
在早期启动阶段，
/var目录尚未挂载，无法将日志文件写入硬盘。因此，内存用于存储并将日志数据写入/run/log/journal。挂载后，所有数据都会刷新到磁盘（systemd-journactl-flush.service）。随后，systemd 服务管理器将调用所有服务进程，默认情况下，标准输出和标准错误都连接到日志。因此，数据流从单元传输到运行目录，再传输到
/var/log。