运维配置管理后端【免费下载链接】saltSoftware to automate the management and configuration of infrastructure and applications at scale.项目地址https://gitcode.com/gh_mirrors/sa/salt点击查看免费下载导读本文围绕 Salt 项目 changelog/69806.fixed.md 记录的缺陷修复展开在 Salt 的 LazyLoader 按需加载机制中当一个__virtualname__被多个兄弟实现模块共享时例如pkg同时被aptpkg、aixpkg等多个平台实现声明如果先被求值的那个模块返回False其失败原因会被错误地写入共享的missing_modules缓存键导致后到的、本应可用的 OS 特定虚拟模块如postgres被随机标记为不可用unavailable。读完本文你将掌握 Salt 模块加载器LazyLoader的虚拟模块解析原理、missing_modules缓存与__virtualname__的交互方式、竞态发生的具体路径以及该修复引入的缓存写入策略与回归测试验证方法。背景Salt 的模块加载机制与虚拟模块Salt 使用一套名为 LazyLoader 的按需加载lazy-load机制来加载 execution modules、states、grains 等各类插件。salt/loader/lazy.py 是这套机制的核心实现其关键设计是模块文件并不在进程启动时全部导入而是在首次访问某个函数键如postgres.create_user时才触发加载_load。加载器内部维护file_mapping磁盘文件到模块名的映射见_refresh_file_mapping、_dict已加载函数、loaded_files、loaded_modules以及missing_modules模块名到失败原因的缓存等状态。所有加载状态在访问和写入时都受self._lock一个threading.RLock见_get_lock保护从而支持多线程并发访问。虚拟模块virtual module是 Salt 让同一逻辑模块在不同平台上有不同实现的手段。一个模块文件可以声明模块级属性__virtualname__指定该文件对外呈现的逻辑名称定义__virtual__()函数返回True加载、False不加载或(False, 失败原因)也可以返回一个字符串表示重命名后的模块名。典型的例子在 salt/modules/aptpkg.py它声明__virtualname__ pkg并在__virtual__()中检查__grains__.get(os_family) Debian是 Debian 系系统上pkg模块的实现而在 AIX 上则由 salt/modules/aixpkg.py 提供同名pkg实现。同理 salt/modules/debian_service.py 与其它平台实现共享service这个虚拟名。这类多个文件共享同一个__virtualname__的模块即为本文所讲的兄弟实现sibling implementation。问题本质missing_modules缓存被共享__virtualname__污染竞态发生的代码路径当用户或内部代码通过loader[postgres.xxx]之类的键访问函数时_load会先按点号取出mod_name如postgres然后调用_iter_files(mod_name)遍历候选文件。_iter_files的遍历顺序是精确匹配mod_name in self.file_mapping部分匹配mod_name in k即文件名包含postgres的所有文件兜底遍历全部文件除非设置了lazy_loader_strict_matching配置项。也就是说当请求postgres.*时deb_postgres、postgres等包含 postgres 字样的所有文件都会被依次尝试_load_module直到某个文件成功加载出目标函数。问题出在_load_module处理__virtual__()的环节salt/loader/lazy.py。对每个候选模块文件代码都会调用_process_virtualsalt/loader/lazy.py执行其__virtual__()若__virtual__()返回False_process_virtual会读取模块的__virtualname__属性若声明且为字符串将module_name替换为该虚拟名后再返回salt/loader/lazy.py例如deb_postgres.py返回(False, deb_postgres, 原因, ())时module_name已被改写为共享的__virtualname__如postgres随后在 salt/loader/lazy.py 中代码会执行self.missing_modules[name] virtual_err # 按真实文件名记录 self.missing_modules[module_name] virtual_err # 按虚拟名记录可能与兄弟模块共享这就是污染点missing_modules[module_name]使用的键是共享的__virtualname__而不是模块文件名。当deb_postgres先被求值并失败时missing_modules[postgres]被写入了deb_postgres的失败原因。随后_inner_load继续尝试下一个候选文件真正的postgres.py但 第 1279 行 的短路检查if mod_name in self.missing_modules or key in self._dict: return True会直接命中缓存——postgres已在missing_modules中于是加载器提前返回真正的postgres.py根本没有机会执行它的__virtual__()。最终表现就是postgres这个本应在装有 psql 的机器上正常加载的模块被随机取决于哪个兄弟文件先被遍历到、先被哪个线程触发加载标记为不可用且报错信息来自无关的deb_postgres。这正是 changelog 中描述的loader race that could randomly mark OS-specific virtual modules as unavailable。并发放大效应LazyLoader 的_load/_load_module受self._lock保护单次加载本身是线程安全的但 Salt 的 Master、Minion 中同一个 LazyLoader 实例可能被多个线程按需触发不同键的加载加载器还提供了run_in_thread等辅助入口见 salt/loader/lazy.py且_iter_files的遍历顺序取决于file_mapping的插入顺序与磁盘目录枚举顺序。因此哪个兄弟文件先被求值在并发场景下是不确定的故障呈间歇性、随机性出现——这正是此类竞态难以排查的原因。修复方案按文件记录 共享虚拟名的失败原因合并针对上述污染路径修复策略分为两层均落实在 salt/loader/lazy.py1. 以真实文件名name为准记录失败name对应磁盘上的真实模块文件名如deb_postgres、postgres是唯一的、不会与兄弟模块冲突的键。现在每个文件失败时始终先写self.missing_modules[name]保证每个文件自身的失败原因不丢、不串。2. 共享虚拟名module_name改为追加式合并当模块声明了与其他文件相同的__virtualname__时missing_modules[module_name]不再直接覆盖而是按以下规则合并salt/loader/lazy.pyif module_name not in self.missing_modules: self.missing_modules[module_name] virtual_err elif virtual_err is not None: existing self.missing_modules[module_name] if existing is None: self.missing_modules[module_name] virtual_err else: existing_str str(existing) new_str str(virtual_err) if new_str and new_str not in existing_str.split(; ): self.missing_modules[module_name] f{existing_str}; {new_str}要点首个失败文件写入其失败原因后续失败文件若原因不同则以; 分隔追加用户能看到所有共享该虚拟名的实现各自失败的原因而不是只看到第一个相同原因去重避免重复拼接。3. 配套的 collision 语义在_process_virtual返回失败时若模块显式声明了__virtualname__module_name会被替换为该虚拟名salt/loader/lazy.py这正是上述合并逻辑所依赖的输入。换句话说修复后的行为是只要有任何同名虚拟模块最终成功postgres就可用只有全部兄弟实现都失败时postgres才会以合并后的完整原因出现在missing_modules中。修复效果验证回归测试仓库在 tests/pytests/unit/loader/test_lazy.py 中新增了回归测试test_virtualname_collision_surfaces_all_reasons其构造与断言完整覆盖了本次修复的语义在临时目录写入两个共享__virtualname__ x509的模块文件x509.py与x509_v2.py二者的__virtual__()分别返回(False, Superseded, using x509_v2)与(False, Could not load cryptography)——模拟真实场景中旧版实现被新版取代、而新版又缺少依赖的情形用LazyLoader加载后断言访问loader[x509.expires]抛出KeyError模块确实不可用断言loader.missing_modules.get(x509)非空且同时包含两个失败原因字符串断言missing_fun_string(x509.expires)生成的用户可读错误信息同样包含两个原因。该测试同时也是回归保护如果将来有人把missing_modules[module_name]改回直接覆盖测试会立即失败。此外salt/loader/lazy.py 的missing_fun_string方法负责把缓存原因格式化为最终错误文案形如x509 __virtual__ returned False: ...这也是修复后用户能从报错中看到全部失败原因的出口。对使用者与模块开发者的影响使用者运维/排障升级到包含该修复的版本后间歇性的某模块随机不可用问题将消失若模块确实不可用报错信息会列出所有共享该虚拟名的实现各自的失败原因排障信息更完整。例如deb_postgres与postgres同时失败时错误中会以; 分隔列出各自原因。模块开发者写 OS 特定虚拟模块时应遵守既定约定——用__virtualname__声明共享逻辑名用__virtual__()返回(False, 原因)提供可诊断信息不要依赖兄弟模块先被求值的偶然顺序也不要试图在__virtual__()中写全局可变状态例如修改__virtualname__本身因为加载顺序在多线程下不可控。加载器行为修复不改变虚拟名最终可用性的判定规则——只要任一兄弟实现加载成功虚拟名即可用仅改变了失败路径下缓存的记录方式按文件记录、按虚拟名合并。对 salt/modules/postgres.py 这类依赖外部二进制psql的模块其__virtual__()返回(False, psql was not found)的失败原因现在能更可靠地被保留与呈现。小结changelog/69806.fixed.md记录的是一个典型的共享缓存键 按需加载 多线程组合下的竞态缺陷missing_modules缓存以共享的__virtualname__为键导致兄弟模块先失败时污染后到模块的加载判定。修复通过按真实文件名记录 共享虚拟名失败原因追加合并消除了污染并用test_virtualname_collision_surfaces_all_reasons固化行为。这套机制也再次印证了 Salt 加载器的设计原则虚拟模块的可用性由__virtual__()动态决定而加载器必须保证这一判定在多线程、多候选文件的场景下既准确又可诊断。赞分享运维配置管理后端【免费下载链接】saltSoftware to automate the management and configuration of infrastructure and applications at scale.项目地址https://gitcode.com/gh_mirrors/sa/salt点击查看免费下载相关推荐深入解析 Salt cp 模块 _client() 对缺失 __file_client__ 上下文的回退修复深入解析 Salt cp 模块 _client 对缺失 __file_client__ 上下文的回退修复 导读 本篇文章围绕 Salt 变更记录 changel运维配置管理后端bCNC与GRBL通信详解从串口设置到实时数据传输全攻略bCNC与GRBL通信详解从串口设置到实时数据传输全攻略 bCNC作为一款强大的GRBL CNC命令发送器、自动调平器和G代码编辑器能够与GRBL控制器进行桌面应用图形学工业制造创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考