【openEuler-22.03-LTS-SP1】ompi-clean -v -d参数执行报错

【环境信息】
openeulerversion=openEuler-22.03-LTS-SP1
compiletime=2022-11-23-18-22-38
gccversion=10.3.1-16.oe2203sp1
kernelversion=5.10.0-126.0.0.66.oe2203sp1
openjdkversion=1.8.0.352.b08-3.oe2203sp1
【软件版本】
openmpi-4.1.4-2.oe2203sp1
【问题复现步骤
1.安装openmpi软件包
2.执行/usr/lib64/openmpi/bin/ompi-clean -d
3.执行/usr/lib64/openmpi/bin/ompi-clean -v
出现概率：必现
【预期结果】
执行命令成功
【实际结果】
执行命令失败
输入图片说明

一、分析过程
第一步：对比2203和2209代码分析发现
1、22.03 LTS版本的openmpi 执行ompi-clean 是支持 non-pmix 工具的， 环境不会通过pmix获取server, 所以clean 操作成功。
2、现行22.09 版本openmpi commit 3c914a7 以后就不再支持 non-pmix 工具了。 ompi-clean 过程中，必须调用pmix包内ptl_base_fns.c 的pmix_ptl_base_check_server_uris 接口。而pmix_ptl_base_check_server_uris 接口获取不到PMIX_SERVER_URI类型的环境变量，返回UNRECHABLE 错误。
2209 orte_init()在22.09已经不再支持non-pmix模式，必须通过pmix获取服务
具体代码见：

22.03 LTS之所以成功是因为在初始化时候支持none-pmix的形式
社区相关提交：
https://github.com/open-mpi/ompi/commit/3c914a7a979273cf5b2bc5bac4e4608880d8af87

第二步：查看slurm和pmix是否有设置PMIX_SERVER_URI环境变量的过程
排查代码依然未发现设置环境变量的过程

第三步：使用openmpi自带的pmix进行分析
查看openmpi的configure配置，关于这个问题涉及到的pmix有两种方式，with-pimx=external
和 with-pmix=internal，不再支持without-pmix
具体如下：

以下也从这两种方式进行分析
1、--with-pmix=external 方式编译出的rpm包，orte_init过程中，会调用pmix包中ptl_base_fns.c提供的接口pmix_ptl_base_check_server_uris来获取服务的MIX_SERVER_URI，接口读取环境变量失败抛出unreachable异常。
2、--with-pmix=internal方式编译出的rpm包，orte_init过程中，df_search 获取服务uri 后，ptl_tcp.c:983 recv_connect_ack接口和服务握手失败，抛出unreachable异常。

第四步：尝试修复
1、 查看上游：目前上游社区属于挂起状态，暂无修改方案，且社区最新已经将orte-clean.c移除
相关提交：https://github.com/open-mpi/ompi/commit/174e967dbc6062
2、 回合支持none-pmix的代码，目前代码重构较大，不好回合，涉及更改（36 files changed, 433 insertions(+), 365 deletions(-) ）且回合后依然走的是pmix的分支，无效
https://github.com/open-mpi/ompi/commit/68029b27e45e

二、影响分析排查
1、orte-clean 作用：Cleans up any stale processes and files leftover from Open MPI jobs
代码查看主要动作为：（1）删除启动session下的文件（里面是以pid命名的文件夹） （2）kill openmpi相关进程
2、对比2203 LTS，2203 LTS在操作orte-clean时，经过gdb调试跟进发现执行上述两个功能时候，等同于操作空函数，具体实际如下：
（1）删除文件时，stat获取不到文件，跳过删除流程
（2）kill 进程，函数直接返回，由于传参源码赋值指定的是unknow，同样跳过实际操作情况，没有执行进程杀死操作
3、22.09 资源泄漏影响，以下是根据代码进行的三种尝试
1）正常执行到MPI_Finalize()退出的程序，会自动清理运行过程中产生的资源
2）MPI_Finalize()之前异常退出，会自动清理运行过程中产生的资源
3）收到signal 被杀死的程序，会自动清理运行过程中产生的资源

综上结合2203 LTS以及openmpi自动回收机制，不存在泄漏风险，且orte-clean和ompirun是两个回收机制，调用接口不一致，不影响，也能说明社区maintainers的说法“orte-clean shouldn't be necessary for normal Open MPI runs.”

综上该问题影响较小，22.03-LTS-SP1的openmpi版本与22.09-LTS一致，所以结论延用22.09版本的评审结论遗留处理
2209相关issue：https://gitee.com/src-openeuler/openmpi/issues/I5PQ3O?from=project-issue

src-openEuler/openmpi

内容风险标识

评论 (2)

src-openEuler/openmpi .gitee-modal { width: 500px !important; }

内容风险标识