/dev/shm/目录下出现超大文件，未被清除

bmc_core SIG
1

问题描述

/dev/shm目录下有大文件（标准分别是大于）且文件有执行权限，执行script目录下的./partition_usage_monitor.sh，文件内存应被清空，变成1B，文件仍存在，实际不会清空，影响文件系统目录监控功能

环境信息

  • 操作系统：[如 Ubuntu 24.04]

  • 软件版本：[如 OpenUBMC2509]

  • 硬件配置：[如 CPU、内存等]

重现步骤

1./dev/shm目录写入个有执行权限的大于100M的文件aaa.txt
2. 执行script目录下的定时脚本，./partition_usage_monitor.sh
3. 查看文件大小没有变化

期望结果

aaa.txt文件被截断为1个字节

实际结果

aaa.txt文件没有被截断

问题根因

iBMC partition_usage_monitor.sh脚本中清除目录：
rm_if_exceed_limit “/dev/shm” 102400
rm_if_exceed_limit “/data” 102400
rm_if_exceed_limit “/opt/pme/pram” 3072
现在版本partition_usage_monitor.sh脚本中清除目录：（/dev/shm目录变小了、并且没有检测/opt/pme/pram目录）
rm_if_exceed_limit “/dev/shm/log” 102400
rm_if_exceed_limit “/dev/shm/persistence.local” 102400
rm_if_exceed_limit “/dev/shm/tallylog” 102400
rm_if_exceed_limit “/var/log” 102400
rm_if_exceed_limit “/data” 102400

期望解决

1、为啥/dev/shm目录只剩下"/dev/shm/log"、“/dev/shm/persistence.local”、 "/dev/shm/tallylog"三个目录，如果/dev/shm目录下出现大文件，不就影响升级功能吗？
2、如果考虑到升级文件解压到/dev/shm目录下，那么是否只考虑将/dev/shm/upgrade目录排查在外不扫描，其他目录还是保持扫描检测呢？
3、为啥不扫描/opt/bmc/pram目录

2

答案内容由AI生成，仅供参考：

/dev/shm 目录下出现超大文件未被清除的问题分析

问题描述

在 openUBMC 系统中，当 /dev/shm 目录下存在大于 100MB 且具有执行权限的大文件（如 aaa.txt）时，执行 /opt/bmc/script 下的 ./partition_usage_monitor.sh 脚本后，该文件大小未被截断为 1 字节，仍然保持原大小。这导致 文件系统目录监控功能失效，影响系统稳定性及升级操作。

环境信息（基于上下文推断）

  • 操作系统：openUBMC
  • 软件版本：Active openUBMC Version: 25.09.00.01
  • 硬件配置：
    • CPU：Hi1711
    • 存储管理组件：busybox/1.34.0@openUBMC.release/stable
  • 相关脚本路径：/opt/bmc/script/partition_usage_monitor.sh

重现步骤

  1. 在 /dev/shm 目录下创建一个大于 100MB 且具有执行权限的文件（如 aaa.txt）
  2. 执行定时脚本：/opt/bmc/script/partition_usage_monitor.sh
  3. 检查 aaa.txt 文件大小

预期结果

  • 文件应被截断为 1 字节，内容清空，但文件保留

实际结果

  • 文件大小 未发生变化，仍为原始大小

根因分析

:white_check_mark: 脚本逻辑变更导致监控范围缩小

对比 iBMC V2 与 openUBMC V3 的 partition_usage_monitor.sh 脚本中 rm_if_exceed_limit 函数调用差异如下：

iBMC V2 openUBMC V3
rm_if_exceed_limit "/dev/shm" 102400
rm_if_exceed_limit "/data" 102400
rm_if_exceed_limit "/opt/pme/pram" 3072		 rm_if_exceed_limit "/dev/shm/log" 102400
rm_if_exceed_limit "/dev/shm/persistence.local" 102400
rm_if_exceed_limit "/dev/shm/tallylog" 102400
rm_if_exceed_limit "/var/log" 102400
rm_if_exceed_limit "/data" 102400

:warning: 关键差异：

  • 原先对整个 /dev/shm 分区进行空间检测，现仅检测其子目录：/dev/shm/log、/dev/shm/persistence.local、/dev/shm/tallylog
  • /opt/pme/pram 路径 已从检测列表中移除，且可能路径已更名或重构

因此，放置于 /dev/shm 根目录下的大文件（如 aaa.txt）不再被脚本识别和处理，导致无法触发清理机制。

回答用户疑问

1. 为什么 /dev/shm 只保留三个子目录监控？是否影响升级功能？

:white_check_mark: 原因分析：

根据当前 openUBMC 架构设计演变趋势（参考 DevmonFaultPredictionPreventionDesign 和 DiskSpaceManagementRecommendations），系统倾向于 精细化日志与临时文件管理，仅对已知会产生大量日志的特定子目录进行监控。

  • /dev/shm/log：系统运行时日志缓存
  • /dev/shm/persistence.local：本地持久化状态存储
  • /dev/shm/tallylog：登录记录统计（类似传统 tallylog）

:pushpin: 风险提示：
当前设计 未涵盖 /dev/shm 根目录 下的任意文件监控，若在此生成大文件（例如调试输出、临时上传等），将逃过自动清理机制，可能导致：

  • 磁盘空间耗尽
  • 升级失败（因空间不足）
  • 影响后续固件激活（Valid 模块依赖文件系统完整性）

:magnifying_glass_tilted_left: 支持证据：

  • tmp Directory 是临时文件操作的关键路径，要求具备 write 权限（见 KG 实体）
  • File Management 要求“删除有效文件以防止重复升级”，说明文件管理直接影响升级安全性

2. 为何不再扫描 /opt/pme/pram 目录？

:magnifying_glass_tilted_left: 路径变更可能性高：

  • 当前上下文中无 /opt/pme/pram 或 /opt/pme/script 路径记录
  • 存在路径 /opt/bmc/apps/file_transfer 和 /opt/bmc/script，表明系统已迁移至新的 BMC 软件结构
  • file_transfer 组件负责数据传输，可能已接管原 /opt/pme/pram 功能

:white_check_mark: 推论：

  • /opt/pme/pram 是 旧版 iBMC 的专用路径
  • openUBMC V3 已重构文件系统布局，将原功能整合进 /data 或 /opt/bmc 目录下
  • 脚本未扫描该路径，是因为 该路径已废弃或重命名

:white_check_mark: 建议：确认是否存在映射路径，例如：

  • /data/tmp → 替代 /opt/pme/pram
  • 或通过符号链接定位真实路径

解决建议

:white_check_mark: 优化方案一：修改 partition_usage_monitor.sh 脚本

增加对 /dev/shm 根目录的监控：

rm_if_exceed_limit "/dev/shm" 102400

同时保留原有子目录监控，确保细粒度控制与整体安全兼顾。

:white_check_mark: 优化方案二：限制 /dev/shm 根目录写入权限

通过挂载选项或权限控制，禁止在 /dev/shm 根目录创建非目录文件：

chmod 1777 /dev/shm        # 保持共享内存目录可用
chmod +t /dev/shm          # 启用 sticky bit，防止误删他人文件

并要求所有大文件必须写入指定子目录（如 /dev/shm/upload）

:white_check_mark: 优化方案三：引入日志与临时文件统一管理机制

结合 Log Rotation 和 Disk I/O Limit Handling 推荐实践：

  • 使用 logrotate 管理日志文件生命周期
  • 启用异步写入和缓存优化，减少瞬时 I/O 压力
  • 参考 DiskSpaceManagementRecommendations 实现自动预警与清理

结论

项目 说明
问题根源 partition_usage_monitor.sh 脚本在 openUBMC V3 中缩小了监控范围，仅覆盖 /dev/shm 的特定子目录，遗漏根目录及 /opt/pme/pram
是否影响升级 是，大文件可能占用空间，阻碍升级包解压、验证（Valid 模块）、激活等流程
是否路径失效 /opt/pme/pram 极可能已被重构或弃用，建议检查当前实际存储路径
推荐措施 修改脚本加入 /dev/shm 整体监控，并强化临时文件管理策略

:link: 参考资源：

  • https://discuss.openubmc.cn/t/topic/1693（xuhaijun 提供的构建问题分析方法）
  • DevmonFaultPredictionPreventionDesign 提出的持续学习与预防机制，适用于此类空间异常预测

:white_check_mark: 最终建议：
修复脚本逻辑，恢复对 /dev/shm 根目录的空间监控，并归档 /opt/pme/pram 路径的历史用途说明，完成系统迁移文档更新。

相关链接：

  1. 模拟/dev/shm满的日志提示
  2. 关于openUBMC中部分进程疑似内存泄漏
  3. 如何清除如下当前告警日志
  4. bmc内存占用率过高
3

@pengqiang-gs 帮忙解答写，非常感谢。
1、之前扫描/dev/shm这个目录，现在只扫描"/dev/shm/log"、“/dev/shm/persistence.local”、 "/dev/shm/tallylog"三个目录，会导致/dev/shm其他目录下超大文件无法被清除，是否存在风险；
比如：/dev/shm目录下出现大文件，不就影响升级功能吗？
2、这里代码是否有优化的空间？

4

@kunlun_xiechuanguan

  1. partition_usage_monitor.sh 脚本不能直接地检测 /dev/shm 目录，因为业务运行过程中会对 /dev/shm/xx 目录做 mount/umount 操作，如果 partition_usage_monitor.sh 脚本检测 /dev/shm/xx目录冲突，会导致 mount/umount 操作失败，影响业务功能；
  2. 当前partition_usage_monitor.sh脚本仅对/dev/shm下面某几个具体目录做检测，这几个目录也是会有运行过程中有出现大文件风险的，其他目录的使用过程中，要有具体对使用空间的校验，不会出现大文件风险；
5

其他目录的使用过程中，要有具体对使用空间的校验，不会出现大文件风险；加黑部分是目前已经有这个校验机制了？还是需要支持，如果需要支持谁去支持这个空间校验？

6

目前在固件缓存的场景已经有使用空间校验，比如要缓存一个新的固件包，要限制其使用空间的大小，还要判断剩余空间的大小，不能因为业务处理导致将/dev/shm空间消耗过度了，如果出现这种情况属于软件bug，不能依靠例测脚本去检测+删除