深入解析cloud-init中set_passwords模块与sshd服务的死锁问题

问题背景

在cloud-init 24.4版本中，存在一个潜在的系统服务死锁问题，该问题发生在set_passwords模块与sshd服务之间。当用户手动启动cloud-init服务时，可能导致系统陷入无限等待状态，影响系统初始化流程。

技术原理分析

这个问题的根源在于cloud-init服务与sshd服务之间的依赖关系形成了一个闭环：

1. 服务依赖关系：cloud-init.service配置了"Before=sshd.service"的依赖关系，意味着cloud-init需要在sshd之前启动
2. 模块执行时机：set_passwords模块被移动到cloud-init的网络阶段执行
3. 服务重启逻辑：当set_passwords模块检测到需要修改sshd配置时，会尝试重启sshd服务

当sshd服务已经运行时，手动启动cloud-init会导致以下死锁链：

• systemd等待cloud-init完成启动
• cloud-init在执行set_passwords时需要重启sshd
• 由于依赖关系，sshd需要等待cloud-init完成才能启动
• 结果就是两个服务互相等待，形成死锁

影响范围

这个问题主要影响以下场景：

1. 在已运行sshd的系统上手动安装并启动cloud-init
2. 在系统初始化后手动重启cloud-init服务
3. 使用systemd作为init系统的发行版

值得注意的是，在正常的云实例启动流程中，这个问题不会出现，因为cloud-init会在sshd启动前完成其初始化工作。

解决方案

上游社区通过以下方式解决了这个问题：

1. 修改服务重启命令：在重启sshd时添加"--job-mode=ignore-dependencies"参数，绕过systemd的依赖检查
2. 条件性应用修改：仅对使用systemd的系统应用此修改
3. 保持向后兼容：确保修改不会影响其他init系统的行为

核心修改逻辑是让sshd的重启操作能够独立于cloud-init服务的状态完成，从而打破死锁循环。

最佳实践建议

基于这个问题的分析，我们建议：

1. 避免手动启动cloud-init服务：cloud-init设计为一次性初始化工具，不是常驻服务
2. 使用官方推荐方式测试：通过cloud-init命令行工具而非systemd服务进行测试
3. 注意版本升级影响：从24.4版本开始，手动启动服务的行为可能不再被支持
4. 构建干净镜像：在镜像构建阶段安装cloud-init但不要启动，确保首次启动行为正确

总结

这个案例展示了系统初始化工具设计中需要考虑的复杂依赖关系。cloud-init团队通过精细的修改既解决了死锁问题，又保持了系统的稳定性和向后兼容性。对于使用者来说，理解工具的设计初衷和正确使用方式同样重要，可以避免许多潜在问题。

对于需要频繁测试cloud-init行为的开发者，建议转向使用cloud-init命令行工具，这不仅能避免类似问题，也是未来版本中更受支持的使用方式。