systemd中PrivateTmp与/var挂载顺序冲突问题分析

在Linux系统启动过程中，systemd作为init系统负责管理和协调各个服务的启动顺序。近期发现一个值得注意的问题：当使用systemd-gpt-auto-generator自动挂载/var分区时，某些服务的PrivateTmp配置可能导致后续启动失败。

问题现象

系统首次启动时表现正常，但第二次及后续启动时会出现/var分区内容丢失的情况。经排查发现，这是由于某些系统服务在/var分区挂载前就尝试创建私有临时目录，导致在根文件系统上创建了/var/tmp目录。当真正的/var分区挂载后，这个残留目录会影响systemd-gpt-auto-generator对分区挂载点的判断。

技术原理

问题的核心在于以下几个技术点的交互：

1. PrivateTmp配置：当服务配置了PrivateTmp=disconnected时，systemd会为该服务创建独立的tmpfs挂载命名空间。这个操作需要在服务启动前完成临时目录的创建。

2. 挂载顺序：对于分离的/var分区，systemd-gpt-auto-generator会在启动过程中自动生成挂载单元。理想情况下，/var分区应该在相关服务启动前完成挂载。

3. 依赖关系：默认情况下，系统服务会通过sysinit.target间接依赖local-fs.target，确保文件系统挂载完成。但某些关键服务（如systemd-resolved）会禁用默认依赖以加快启动。

影响范围

该问题主要影响以下服务：

• systemd-timesyncd
• systemd-resolved
• systemd-oomd
• systemd-coredump

这些服务共同特点是：

• 配置了PrivateTmp=disconnected
• 禁用了默认依赖关系(DefaultDependencies=no)
• 需要在早期启动阶段运行

解决方案

目前可行的解决方案包括：

1. 显式添加挂载依赖： 在受影响的服务单元中添加After=var.mount依赖，确保/var分区挂载完成后再启动服务。

2. 调整PrivateTmp配置： 将PrivateTmp=disconnected改为PrivateTmp=yes，避免在服务启动前创建实际目录。

3. 系统级修复： 在systemd核心代码中增加对挂载状态的检查，确保在挂载命名空间操作前相关挂载点已就绪。

最佳实践建议

对于系统管理员和发行版维护者：

1. 在部署分离/var分区的系统时，应特别注意早期启动服务的依赖关系
2. 对于自定义服务单元，谨慎使用DefaultDependencies=no配置
3. 定期检查系统日志，关注挂载相关的警告信息
4. 在系统更新后，验证关键挂载点的完整性

该问题的发现和解决过程体现了Linux启动过程中各组件间复杂的交互关系，也提醒我们在优化启动速度时需要全面考虑系统状态的完整性。