EL9环境NFS子目录下Python多进程os.cwd()报错问题排查

问题核心现象 #

• 仅在EL9（内核版本如5.14.0-362.18.1.el9_3.x86_64）的NFS挂载子目录中出现，EL7无此问题
• 使用Python multiprocessing 的spawn启动方式，调用pool.terminate()后，频繁触发os.getcwd()返回No such file or directory错误
• 提前调用pool.join()或在terminate()前加短sleep可规避问题，报错后需手动chdir或等待NFS缓存过期恢复
• rpcdebug显示NFS getattr操作返回-512错误，怀疑与根挂载/子挂载的struct dentry行为差异有关

可能的原因方向 #

1. EL9内核NFS客户端的dentry缓存/生命周期差异 #

EL9采用的5.14内核相比EL7的3.10内核，NFS客户端子系统有大量重构：

• 子目录挂载的dentry回收逻辑可能存在变化，pool.terminate()强制终止子进程时，可能触发父进程cwd对应的dentry被提前回收
• -512错误对应EIO，结合NFS场景，大概率是客户端向服务器发起getattr请求时失败，或服务器返回了无效的inode信息
• 检查EL9内核中nfs_dentry_revalidate、nfs_lookup相关逻辑的变更，对比EL7的实现差异

2. Python multiprocessing spawn的cwd继承/处理逻辑 #

spawn方式会重新启动Python解释器，子进程会继承父进程的cwd：

• 当父进程在NFS子目录下创建进程池，pool.terminate()强制终止子进程时，可能触发内核层面的cwd关联资源异常释放
• 对比EL7和EL9上Python的multiprocessing模块实现差异，尤其是spawn启动时cwd的传递、子进程退出后的资源清理逻辑
• 测试直接用os.fork()+os._exit()模拟terminate()的暴力退出，看是否能复现相同问题，排除Python封装层的影响

3. NFS服务器端的处理逻辑差异 #

虽然EL7无问题，但不排除服务器对EL9客户端的请求处理存在兼容性问题：

• 检查服务器端NFS日志，看是否有对应getattr请求的错误记录
• 测试将NFS挂载参数调整为noac（禁用属性缓存），看是否能缓解或消除问题，验证是否与客户端缓存过期逻辑有关
• 对比EL7和EL9客户端发送的NFS请求报文差异（比如RPC版本、请求参数）

排查步骤建议 #

1. 内核层面验证：

   • 手动编译EL9内核并临时禁用NFS客户端的某些优化（如dentry缓存回收），测试是否复现问题
   • 查看内核日志dmesg中是否有NFS相关的警告或错误信息，尤其是dentry回收、inode失效相关的内容

2. Python层面验证：

   • 在pool.terminate()前，手动将父进程的cwd切换到本地目录（而非NFS），看是否还会触发错误
   • 替换multiprocessing为concurrent.futures.ProcessPoolExecutor（底层同样用spawn），验证是否存在相同问题
   • 测试不同版本的Python（如3.9、3.11）在EL9上的表现，排除Python版本特定的bug

3. NFS挂载参数调整测试：

   • 尝试添加挂载参数lookupcache=none、noac，禁用客户端的查找缓存和属性缓存
   • 测试将子目录改为单独挂载（而非顶级挂载的子目录），看问题是否消失，验证是否与子目录的挂载层级有关

4. dentry状态检查：

   • 报错后，使用ls -ld /proc/self/cwd查看cwd的inode信息，对比NFS服务器上对应目录的inode
   • 使用debugfs或内核调试工具（如ftrace）跟踪dentry的创建、回收过程，看是否存在异常释放

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