Debian 与其他发行版在 ulimit 上的差异
一 配置加载链与 PAM 的差异
- 通用机制相同：大多数发行版都通过 /etc/security/limits.conf（以及 /etc/security/limits.d/ 目录）定义用户级限制，并依赖 PAM 的 pam_limits.so 在登录会话时加载这些限制。Debian 的典型做法是确保会话配置（如 /etc/pam.d/common-session 与 /etc/pam.d/common-session-noninteractive）包含该行，否则 limits.conf 不会生效。
- 发行版细微差别：基于 Debian/Ubuntu 的系统通常在 PAM 会话配置中使用上述两个文件；而 RHEL/CentOS 常见的是在 /etc/pam.d/login、/etc/pam.d/sshd 中启用 pam_limits.so。路径与启用方式不同，但本质机制一致。
二 Systemd 作用域与默认值的差异
- 作用域差异：使用 systemd 的发行版（包括 Debian）中，服务（PID 1 的 systemd 作用域及其派生的服务单元）默认不会读取 limits.conf，需要在 /etc/systemd/system.conf 与（必要时）/etc/systemd/user.conf 中通过如 DefaultLimitNOFILE=… 等参数设置；而通过 SSH/控制台登录的交互式会话仍走 PAM/limits.conf。
- 默认值倾向：社区经验中常见到 CentOS/RHEL 的默认文件描述符限制较为保守（如常见为 1024 或更低），而 Debian/Ubuntu 往往更宽松（如 4096 或更高）。具体数值仍取决于版本、内核与系统配置。
三 通配符与 root 的处理
- 通配符行为：在 limits.conf 中，Debian 环境下常见到 “ 通配符不匹配 root”* 的实践/注意事项，这意味着对 root 的限制需要显式书写；而在 CentOS/RHEL 环境中，“*” 通常可以匹配 root。这是管理员在跨发行版维护 limits.conf 时容易忽略的差异点。
四 易踩坑与排查要点
- 登录方式影响生效：图形登录、SSH、su、sudo、cron、systemd 服务等加载链不同，可能导致 limits.conf 未被应用；需核对对应 PAM 配置与 systemd 作用域配置是否到位。
- 服务与容器差异：已启动的 systemd 服务 不会自动感知 limits.conf 的新改动，需要重启或在 unit 文件中显式设置 LimitNOFILE=；在 容器（如 Docker）中，容器内限制通常需要在运行时通过 –ulimit 指定，宿主机配置不会直接透传。
- 生效验证：登录后或进入目标会话后执行 ulimit -a 查看软/硬限制；对服务，使用 systemctl show | grep Limit 检查实际生效值。
五 快速对照表
| 维度 |
Debian/Ubuntu |
RHEL/CentOS |
| 登录会话加载 |
PAM 会话文件：/etc/pam.d/common-session、common-session-noninteractive |
PAM 会话文件：/etc/pam.d/login、/etc/pam.d/sshd |
| Systemd 全局默认 |
编辑：/etc/systemd/system.conf、/etc/systemd/user.conf；服务需重启或 unit 中设置 Limit* |
同左 |
| 默认文件描述符倾向 |
常见为4096或更高 |
常见为1024或更低 |
| 通配符与 root |
“*” 常不匹配 root，需显式为 root 配置 |
“*” 通常匹配 root |
以上差异点可帮助在跨发行版运维时快速定位“为什么设置了 limits.conf 却没生效”的根因，并选择正确的配置路径与验证方式。
