Fast DDS共享内存文件异常消失问题分析与解决

问题背景

在使用Fast DDS进行进程间通信时，开发者遇到了一个关于共享内存(SHM)传输的异常问题。具体表现为：在ARM64架构的Ubuntu 22.04系统上运行约30个节点时，初始阶段节点间通信正常，但运行一段时间后消费者节点无法接收数据，检查发现/dev/shm目录下的共享内存文件意外消失。

问题现象

1. 节点间初始通信正常
2. 运行一段时间后消费者无法接收数据
3. /dev/shm下的共享内存文件消失
4. 该问题在x86架构上未出现，仅在ARM64架构设备上复现
5. 影响Fast DDS 2.6.8和2.6.9版本

技术分析

共享内存是Fast DDS实现高效进程间通信的重要机制，它通过在/dev/shm目录下创建内存映射文件来实现数据共享。当这些文件异常消失时，会导致通信链路中断。

经过深入排查，发现问题根源在于系统服务systemd-logind的行为。具体机制如下：

1. /usr/lib/systemd/systemd-logind服务负责管理系统登录会话
2. 当所有用户注销登录时，该服务会自动清理该用户创建的所有临时文件
3. 这种清理行为包括/dev/shm目录下的共享内存文件
4. 在ARM架构设备上，这种清理行为表现得更为激进

解决方案

针对这一问题，可以采取以下几种解决方案：

1. 保持用户会话活跃：确保至少有一个用户会话保持登录状态，防止systemd-logind触发清理机制

2. 修改systemd-logind配置：通过编辑/etc/systemd/logind.conf文件，调整清理行为：

   RemoveIPC=no
   

   修改后需要重启服务：

   systemctl restart systemd-logind
   

3. 使用其他传输机制：对于关键通信链路，可以考虑使用TCP或UDP传输作为备份方案

4. 监控和重建机制：在应用层实现对共享内存文件的监控，发现文件丢失时自动重建通信链路

最佳实践建议

1. 在生产环境中部署Fast DDS时，应对系统服务的行为进行全面评估
2. 对于依赖共享内存的关键应用，建议实施冗余通信机制
3. 在不同架构平台部署前，应进行充分的兼容性测试
4. 定期检查系统日志，监控共享内存使用情况

总结

Fast DDS的共享内存传输机制虽然高效，但在实际部署中可能受到系统服务的干扰。理解系统底层机制对于解决这类隐蔽问题至关重要。通过合理配置系统参数和应用层防护措施，可以有效避免共享内存文件异常消失导致的通信中断问题。