CentOS 6下Buildbot夜间编译GCC报错：无法读取/tmp目录下.s文件

我之前帮人处理过类似的Buildbot构建故障，结合CentOS 6的环境特性，给你梳理几个针对性的排查方向和解决办法：

一、先确认临时文件的生命周期与Buildbot运行上下文 #

• 检查Buildbot Worker的运行用户：用ps aux | grep buildbot查看worker进程的运行用户，对比出错时预期生成的.s文件属主。如果不同构建任务用了不同用户，或者有其他进程以root身份清理文件，可能会误删不属于自己的临时文件。
• 验证编译器临时目录配置：GCC等编译器默认使用/tmp作为临时目录，但Buildbot任务里可能不小心覆盖了TMPDIR环境变量。可以在构建脚本中加入echo $TMPDIR，确认临时目录路径是否正确。

二、排查系统层面的临时文件清理机制（除tmpwatch外） #

CentOS 6上除了tmpwatch，还有其他可能清理/tmp的机制：

• 检查定时任务：查看root和Buildbot运行用户的crontab -l，再排查/etc/cron.d/、/etc/cron.hourly/、/etc/cron.daily/下的所有脚本，看有没有自定义的/tmp清理逻辑。
• 检查/tmp挂载属性：用mount | grep /tmp确认/tmp是否为tmpfs挂载。如果是，内存不足时内核可能会自动回收tmpfs空间，导致文件丢失。可以用df -h /tmp和free -m监控构建过程中的空间和内存使用。
• 查找其他清理工具：用find /etc -name "*tmp*"搜索相关配置文件，排查是否有第三方安全工具或系统脚本在清理临时文件。

三、针对编译器与Buildbot任务的调试 #

• 开启编译器详细日志：在Buildbot的编译命令中添加-v参数（比如GCC的-v），输出编译过程的完整步骤，通过日志确认.s文件生成后是在哪个环节消失的。
• 使用专属临时目录：在构建脚本开头创建一个专属临时目录，例如：

  BUILD_TMP=/tmp/buildbot_$(date +%s)_$$
  mkdir -p $BUILD_TMP
  export TMPDIR=$BUILD_TMP
  

  让编译器将临时文件放到这个专属目录，避免全局清理工具误删。构建完成后再执行rm -rf $BUILD_TMP清理。
• 关闭并发构建测试：如果Buildbot开启了多worker或同一worker并发执行任务，可能存在任务间互相干扰的情况。暂时关闭并发，观察故障是否消失。

四、追踪文件删除的具体进程 #

• 用inotifywait监控/tmp：先安装inotify-tools（yum install inotify-tools），在构建期间执行：

  inotifywait -m -e delete --format '%w%f deleted by %p' /tmp
  

  这条命令会记录所有删除/tmp文件的操作，故障发生时就能直接看到是哪个进程删除了目标.s文件。
• 用strace跟踪编译器：对编译命令进行系统调用跟踪，例如：

  strace -e open,unlink,rmdir YOUR_COMPILE_COMMAND
  

  通过输出可以看到编译器对临时文件的操作细节，判断文件是被编译器自身删除还是被外部进程清理。

最终解决建议 #

如果排查后确认是系统全局清理工具误删临时文件，最稳妥的方案是给Buildbot配置专属临时目录：

1. 在Buildbot Worker的启动脚本中添加环境变量：

   export TMPDIR=/var/tmp/buildbot
   

2. 确保目录权限正确：

   chown buildbot:buildbot /var/tmp/buildbot
   chmod 700 /var/tmp/buildbot
   

3. 在构建脚本中也明确设置TMPDIR，避免被任务内的脚本覆盖。

这样可以彻底隔离系统清理机制对Buildbot临时文件的影响。

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