当前位置：首页 > news >正文

OAT 初始化时出错？问题可能出在 PAM 配置上｜OceanBase 故障排查实践

news 来源：原创 2025/6/19 4:16:12

本文作者：爱可生数据库工程师，任仲禹，擅长故障分析和性能优化。

背景

某客户在使用 OAT 初始化OceanBase 服务器的过程中，进行到 precheck 步骤时，遇到了如下报错信息：

ERROR - check current session hard limit of open_files (ulimit -H -n): 4096 != 655350 ... EXPECT 655350 ... FAIL

错误大意：OAT 需要服务器的 ulimit -H -n 命令返回值是 655350，实际得到的是 4096。

下图所示，虚拟机因磁盘和内存规格不足而触发了检查错误提示（此信息可以忽略）。

排查过程

① 检查当前服务器的 ulimit 值

使用 SSH 登录到目标服务器检查。

结果：【不符合预期】

使用 su 切换到服务器 admin 用户检查。

结果：【符合预期】

这里就有问题，OAT 在 prepare 之前，已经有步骤对服务器的内核参数完成了调整，如下图所示。

这里的 oceanbase_limits.conf 是 OAT 生成的，属于全局配置生效。

理论上不应该出现 SSH 到服务器与 SU 到服务器查出 ulimit 结果不一致的情况。

② 检查 OAT 对于 ulimit 的检查机制

OAT 检查该步骤是运行的程序是 init_server_with_tag.py。

[2024-09-27T16:34:52.775+0800] INFO - Running: ['airflow', 'tasks', 'run', 'init_server_with_tag', 'precheck', 'manual__2024-09-27T08:34:21.675314+00:00', '--job-id', '39950', '--raw', '--subdir', 'DAGS_FOLDER/init_server_with_tag.py', '--cfg-path', '/tmp/tmp5ni__moh']

登录到 OAT 容器，查看程序最终的调用如下。

# 脚本 task_engine/dags/init_server_with_tag.pydef precheck():ctx = get_current_context()common.server_precheck(ctx, logger=logger)# 脚本 task_engine/plugins/common.py
def server_precheck(ctx, logger):init_tag = ctx['params']['init_tag']role = _get_server_role(init_tag)envs = _get_custom_user_env(ctx['params'])with ServerRemoteExecute(server_id=ctx['params']['server_id']) as client:precheck_sh = SHELL_PATH / 'precheck.sh'ret_code, _ = client.execute_script(precheck_sh, args=('-m', role), control_master=False, logger=logger,env={'LC_ALL': 'en_US.UTF-8', 'OB_IP': client.server['ip'], **envs})if ret_code != 0:raise RuntimeError('server precheck failed, please see the summary info above for details')# 脚本 task_engine/shells/precheck.sh
check_limit() {limit_type_list=(-H/hard -S/soft)for limit in "${EXPECT_LIMITS[@]}"dolimit_option=$(echo $limit | awk -F'/' '{print $1}')expect_limit=$(echo $limit | awk -F'/' '{print $2}')limit_description=$(echo $limit | awk -F'/' '{print $3}')limit_item=$(echo $limit | awk -F'/' '{print $4}')for limit_type in "${limit_type_list[@]}"dolimit_type_option=$(echo $limit_type | awk -F'/' '{print $1}')limit_type_description=$(echo $limit_type | awk -F'/' '{print $2}')get_limit_cmd="ulimit $limit_type_option $limit_option"# check new sessioncurrent_limit=$(runuser - "$EXPECT_USER" -c "$get_limit_cmd")if ! compare_ulimit "$current_limit" "$expect_limit"; thenecho_fail "check permanent $limit_type_description limit of $limit_description ($get_limit_cmd): $current_limit != $expect_limit ... EXPECT $expect_limit"echo_hint "modify /etc/security/limits.d/oceanbase_limits.conf\n  echo \"*   $limit_type_description    $limit_item    $expect_limit\" >> /etc/security/limits.d/oceanbase_limits.conf"elseecho_pass "check $limit_type_description limit of new session $limit_description ($get_limit_cmd): $current_limit"fi# check current sessioncurrent_limit=$($get_limit_cmd)if ! compare_ulimit "$current_limit" "$expect_limit"; thenecho_fail "check current session $limit_type_description limit of $limit_description ($get_limit_cmd): $current_limit != $expect_limit ... EXPECT $expect_limit"echo_hint "excute: ulimit $limit_type_option $limit_option $expect_limit"elseecho_pass "check $limit_type_description limit of $limit_description ($get_limit_cmd): $current_limit"fidonedone
}

这里 OAT 获取 ulimit 结果不符合预期的原因已清楚：

通过检查脚本，OAT 是通过 ServerRemoteExecute 模块（使用 SSH 方式）去目标服务器上执行 prepare.sh 脚本做 *ulimit 检查（与预期的 ulimit 值进行对比）。

但是，通过 SSH 连到服务器上执行 ulimit 命令的执行结果不符合预期，甩出报错。

③ 疑问：为何 SSH 连接时 ulimit 值不正确？

先使用 strace 命令查看下 su 时的系统调用。

strace -o /root/l1 su - admin

SU 的结果

SU 时，将调用 /usr/lib64/security/pam_limits.so 文件，继而获取到如下两个文件的 ulimit 配置：/etc/security/limits.conf 和 /etc/security/limits.d/oceanbase_limits.conf。

所以，su - admin 命令执行的结果【符合预期】。

通过系统日志 /var/log/secure 可以看到，SU 操作加载了 pam 插件。

Oct 14 17:44:44 10-186-58-85 su: pam_unix(su-l:session): session opened for user admin by root(uid=0)

从结果反推下，为什么 SSH 不去读取 /usr/lib64/security/pam_limits.so 文件？

根据关键字，猜测跟 SSH 的 PAM 插件有关，继续检查 ssh_config 配置文件如下。

UsePAM no

目标服务器的 PAM 确实是关闭的。
通过系统日志 /var/log/secure 可以看到，SSH 操作没有加载 pam 插件。

Oct 14 17:50:40 10-186-58-85 sshd[25117]: Accepted publickey for root from 10.186.58.85 port 19118 ssh2: RSA SHA256:+TtbeuvInWm90vrJG7cHHm2G2a2FULFE0Uq+imx2m30

引申：PAM 的作用？

这里 ChatGPT 了一下，解释非常清楚如下图，总结一句就是：

关闭 PAM，用户 SSH 到服务器时，将不会读取 *limits.conf 的配置，继而导致获取到默认配置而使 OAT 报错。

解决方法

将配置文件 /etc/ssh/sshd_config 中的 UsePAM 修改为 yes ，重启 SSHD 服务即可。

启用 PAM 插件后，再次 SSH 可以看到系统日志如下多了加载 pam_unix(sshd:session) 的操作。

Oct 14 17:51:56 10-186-58-85 sshd[26147]: Accepted publickey for root from 10.186.58.85 port 19480 ssh2: RSA SHA256:+TtbeuvInWm90vrJG7cHHm2G2a2FULFE0Uq+imx2m30
Oct 14 17:51:56 10-186-58-85 sshd[26147]: pam_unix(sshd:session): session opened for user root by (uid=0)

原因分析总结

OAT 在初始化服务器预检查过程中报告了 ulimit 值不符合预期的错误，这一问题的根源在于目标服务器的 sshd_config 配置不当。
sshd_config 中禁用了 PAM 插件，导致 OAT 无法读取到目标服务器上经过优化的 ULIMIT 配置文件。

背景