pam_limits 触发大量 pam_unix(session) 日志的根本原因是其在会话建立时误配于 auth 段或与 systemd 冲突，导致重复调用并间接触发 pam_unix 记录；应仅限 session 段使用，配合 rsyslog 精准过滤和 systemd 资源配置优化。
为什么 pam_limits 会触发大量 pam_unix(session) 日志
根本原因是 pam_limits.so 模块在每次会话建立时（比如 SSH 登录、su 切换、systemd 用户实例启动）都会调用 pam_get_user() 和 pam_get_item()，而某些 PAM 配置下它会间接触发 pam_unix.so 的 session 模块执行——尤其是当 /etc/security/limits.conf 或 /etc/security/limits.d/*.conf 中存在通配符（如 *、%wheel）且未显式禁用 session 类型时。
典型诱因包括：
-
auth [default=ignore] pam_limits.so被误写在auth段（应只用于session段） - 使用了旧版兼容配置，如
session required pam_limits.so但系统同时启用了pam_systemd.so，导致每个 systemd user session 反复重入 limits 处理 -
limits.conf中某条规则含soft nofile等字段，而内核或 libc 对该资源检查返回 EPERM，pam_unix将失败记录为 session open error
如何定位刷屏日志是否真由 pam_limits 引起
别猜，直接查日志上下文和模块调用链：
- 用
journalctl -u sshd -n 100 --no-pager | grep -A2 -B2 "pam_unix\|pam_limits"看相邻行是否出现pam_limits: set limit: nofile=65536后紧跟pam_unix(sshd:session): session opened for user xxx - 检查 PAM 配置加载顺序：
grep -r "pam_limits\.so" /etc/pam.d/，重点关注sshd、common-session、system-auth中的段类型（auth/account/session） - 临时注释掉所有
pam_limits.so行，重启sshd并观察日志是否停止刷屏（验证用，勿长期保留）
用 rsyslog 过滤丢弃特定 pam_unix session 日志
不推荐全局关闭 pam_unix 日志，而是精准匹配丢弃。关键在于利用 msg 字段中稳定出现的字符串（不是 PID 或时间戳），例如：
if $programname == 'sshd' and $msg contains 'pam_unix(sshd:session): session opened for user' then stop if $programname == 'su' and $msg contains 'pam_unix(su:session): session opened for user' then stop
注意点：
- 必须放在
/etc/rsyslog.d/下独立文件（如10-pam-discard.conf），且文件名需以数字开头确保加载优先级高于默认规则 -
stop是 rsyslog v8+ 语法；v7 用~，但建议升级或确认版本：rsyslogd -v | head -1 - 不要匹配太宽，比如只写
contains 'pam_unix'会误杀认证失败等真正需告警的日志 - 修改后必须
sudo systemctl restart rsyslog，否则不生效
pam_limits 安全与功能的平衡写法
既要限制资源，又不能制造日志噪音，核心是：只在必要位置加载，且避免重复触发。
- 删掉所有
auth和account段中的pam_limits.so—— 它只应在session段生效 - 在
/etc/pam.d/common-session中写成：session [success=ok default=ignore] pam_limits.so，用[success=ok]让成功时不继续后续模块，减少冗余调用 - 若用 systemd，确认
/etc/systemd/logind.conf中UserTasksMax和LimitNOFILE已设好，可酌情减少pam_limits负担 - 对容器或 CI 环境，直接在
/etc/security/limits.d/00-nofile.conf中加* soft nofile 65536即可，无需动 PAM 主配置
最易被忽略的是：systemd 用户会话（systemd --user）会绕过传统 PAM session 链，此时 pam_limits 根本不生效，得靠 systemd-logind 或 user.conf 控制——刷屏日志却可能还来自它试图 fallback 的残留逻辑。
