Yocto启动bitbake时依赖缓存偶发未加载 配方解析耗时过长

问题表现 #

启动bitbake时出现依赖缓存为空提示，全量解析recipes耗时数分钟，每次执行bitbake命令需等待6-7分钟才能完成recipes解析，严重影响开发效率。
运行日志输出如下：

Loading cache: 100%                                         | ETA:  --:--:--
Loaded 0 entries from dependency cache. 
Parsing recipes:   1% |#                                    | Time:  0:06:20

问题特征 #

• 故障为偶现：少数场景下缓存可正常加载，说明缓存机制本身功能正常，多数场景下缓存加载失败，初期难以定位具体诱因
• 删除构建目录下的.lock文件无法解决问题
• 核心异常逻辑：程序尝试加载的带哈希后缀的bb_cache.dat文件实际不存在，例如程序尝试加载bb_cache.dat -> bb_cache.dat.8766c4ab6f5e02381cb595498695990e54b0e58d7e7aed06cfdf517975时，该文件实际不存在；后续程序启动全量recipes解析，解析完成后会生成前述缺失的缓存文件，但下次启动bitbake时，要么可成功加载上次生成的缓存文件，要么大概率会查找一个带新哈希后缀的缓存文件且查找失败，该现象循环往复出现。

根因说明 #

bb_cache.dat后缀的哈希值是bitbake根据当前所有配置项（包括环境变量、conf文件配置、layer配置等）计算出来的配置签名，只要参与签名计算的任意配置项发生变化，哈希值就会改变，bitbake就会去查找对应新哈希的缓存文件，找不到就触发全量解析。
导致哈希值反复飘变的常见原因：

• shell环境中存在动态变化的变量（比如会话级随机变量、自动注入的时间戳变量等）被纳入配置签名计算范围，没有加入哈希计算白名单
• 存在自动化脚本在每次bitbake启动前无意义修改conf/local.conf、conf/bblayers.conf内容，比如追加动态时间戳、临时路径等每次都变的配置
• 构建目录放在NFS、SMB等网络共享存储上，文件元数据读取不稳定导致配置哈希计算结果飘移
• 多终端同时启动bitbake进程，缓存初始化阶段存在读写竞争，导致签名计算或缓存文件写入异常

修复步骤 #

1. 对比两次启动（一次缓存加载成功、一次加载失败）时的配置差异：分别在两次启动时执行bitbake -e > env_<success/fail>.log，导出完整环境配置后做diff，找到值发生变化的配置项，将不需要参与签名校验的动态变量追加到BB_HASHCONFIG_WHITELIST变量中，排除其对哈希计算的影响
2. 检查所有和构建流程绑定的自动化脚本，禁止每次启动bitbake前对conf目录下配置文件做无意义的动态写入，固定非必要不修改的配置项
3. 将构建目录迁移到本地磁盘存储，不要放在网络共享盘上，规避文件属性读取不稳定问题
4. 如果存在并发调用bitbake的场景，加全局进程锁保证同一时间只有一个bitbake进程执行缓存初始化操作，避免读写竞争

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