AzurLaneAutoScript项目磁盘空间被core dump文件占满问题分析

问题现象

在使用AzurLaneAutoScript(简称Alas)自动化脚本过程中，用户发现工作目录下产生了大量名为core.xxx的文件，这些文件占用了大量磁盘空间。同时用户还观察到Alas经常卡在"Loading OCR model: ./bin/cnocr_models/azur_lane"阶段，导致需要频繁进行强制重启操作。

问题原因分析

core dump文件产生机制

core.xxx文件是Linux/Unix系统中的核心转储文件，当程序异常终止时，系统会将程序的内存状态保存到这些文件中，用于后续调试分析。在默认配置下，系统不会生成这些文件，需要满足以下条件才会产生：

1. 系统启用了core dump功能
2. 用户空间限制允许生成core文件(通过ulimit -c设置)
3. 程序异常终止(如被强制杀死)

与Alas的关系

在用户案例中，这些core文件的产生并非直接由Alas的代码缺陷导致，而是由于：

1. 用户在Alas卡住时频繁使用"强制重启"功能
2. 系统配置允许生成core dump文件
3. 强制终止进程的行为触发了系统的core dump机制

解决方案

短期解决方案

1. 清理现有core文件：可以安全删除这些core dump文件以释放磁盘空间

   rm -f core.*
   

2. 禁用core dump生成：

   • 临时禁用(当前会话有效)：

     ulimit -c 0
     

   • 永久禁用：修改/etc/security/limits.conf文件，添加：

     * hard core 0
     

长期解决方案

1. 优化OCR模型加载：

   • 确保使用性能足够的硬件运行Alas
   • 考虑使用更高效的OCR模型
   • 检查模型文件完整性，必要时重新下载

2. 改进异常处理：

   • 为OCR加载过程添加超时机制
   • 实现更优雅的进程终止方式

3. 系统配置调整：

   • 设置core文件大小限制
   • 配置core文件保存路径，避免污染工作目录

技术建议

1. 监控磁盘空间：设置定期清理任务或监控脚本，防止core文件堆积

2. 日志分析：当Alas卡住时，应先检查日志文件而非直接强制重启

3. 性能优化：对于资源受限的环境，可以考虑：

   • 减少同时运行的任务数量
   • 使用轻量级OCR替代方案
   • 增加系统交换空间

总结

core dump文件占满磁盘空间的问题本质上是系统配置与使用方式共同作用的结果。通过合理配置系统参数和优化Alas的运行环境，可以有效避免此类问题的发生。对于自动化脚本的长期稳定运行，建议用户关注系统资源使用情况，并建立适当的监控机制。