为何Systemd清理我的SHM文件却保留PostgreSQL的？及相关问题

1. 为什么Systemd不清理PostgreSQL的SHM文件，却清理我的？ #

核心差异在于进程的运行上下文和服务类型：

• PostgreSQL是以系统级systemd服务运行的，通常使用专门的系统用户（如postgres），归属system.slice管理，其IPC资源属于系统会话范畴，不受普通用户登出触发的RemoveIPC规则影响。
• 你的应用如果是用户级systemd服务（比如配置文件放在~/.config/systemd/user/下），或者运行在普通用户会话中，当你登出服务器时，logind的RemoveIPC=yes会自动清理该用户会话下的所有IPC资源，包括你创建的POSIX共享内存文件。

另外，PostgreSQL在创建SHM时会设置严格的权限（仅允许自身运行用户访问），且服务配置默认规避了logind的清理逻辑，进一步避免了文件被删除。

2. 如何修改应用，和PostgreSQL保持一致以减少运维工作量？ #

可以从这几个方向调整：

• 转为系统级systemd服务：将应用的服务配置文件放到/etc/systemd/system/目录下，而非用户个人目录。创建一个专属系统用户（比如your-app-user）来运行应用，脱离普通用户会话的管理范围，这样IPC资源不会因用户登出被清理。
• 在service文件中禁用IPC清理：在应用的.service配置文件中添加RemoveIPC=no项，即使系统默认规则变化，也能确保SHM文件不被自动清理。
• 优化SHM创建逻辑：创建SHM文件时设置合适的权限（比如仅允许应用运行用户读写），同时在应用启动时检查SHM文件是否存在——如果不存在则重新创建并映射，避免依赖文件的持久化存在。

3. SHM文件被清理后仍可使用，是否可以忽略该情况？ #

是的，当前已完成mmap映射的内存区域可以继续正常使用——POSIX共享内存文件只是内核管理内存的一个"入口"，文件被删除后，只要进程还持有映射的内存区域，内核就不会释放这块内存。

但要注意两个风险：

• 如果应用后续需要重新打开或映射该SHM文件（比如应用重启、新增进程需要共享内存），此时文件已不存在，会导致操作失败，必须重新创建。
• 系统重启后，所有共享内存都会被内核释放，无论文件是否存在，重启后都需要重新创建SHM并映射。

如果应用是单进程运行且无需重新映射，暂时可以忽略，但生产环境建议按问题2的方案优化，避免后续出现意外故障。

内容的提问来源于stack exchange，提问作者Leon