登录级限制怎么生效
limits.conf 是 PAM 模块 pam_limits 的配置文件：用户通过 PAM 登录（SSH、su -、登录终端）时，会话会按文件规则设定 ulimit 值，例如最大打开文件数、进程数、core 文件大小。它只作用于登录会话，改完必须重新登录；由 PID 1 直接拉起的 systemd 服务没有 PAM 会话，因此不受它约束，需要限制服务就得写 unit 里的 LimitNOFILE、LimitNPROC。
基本信息
| 配置文件 | /etc/security/limits.conf、/etc/security/limits.d/*.conf |
|---|---|
| 配置字段 | 域（用户或组） 类型（soft/hard） 项目 值 |
| 生效机制 | pam_limits 在登录会话建立时套用 |
| 生效时机 | 重新登录后生效，当前会话不变 |
| 服务侧 | unit 的 LimitNOFILE/LimitNPROC/LimitCORE |
| 查看当前值 | ulimit -a、ulimit -n、cat /proc/<PID>/limits |
典型使用场景
- 中间件要求进程可打开文件数很大，需要给专属账号放开 nofile
- 避免服务崩溃时生成巨大 core 文件把磁盘写满
- 多用户开发机上限制单用户可创建的进程数
- 交付验收时按规范统一下发登录限制
- 排查『手工启动正常、服务启动报 too many open files』的差异
配置示例与验证
配置示例与验证
# /etc/security/limits.d/90-app.conf
# appuser soft nofile 65535
# appuser hard nofile 65535
# * soft core 0
cat /proc/sys/fs/file-max # 先看内核全局上限，配置值不应超过它
su - appuser -c 'ulimit -n' # 完整登录方式验证，输出应为 65535
su - appuser -c 'ulimit -Hu' # 看硬限制，软限制不能反向超过硬限制
cat /proc/$(pgrep -u appuser -n)/limits | head # 看实际运行进程的限制（比 ulimit 更准）服务侧限制写法
服务侧限制写法
# systemd 服务需要单独配置：
systemctl edit myapp
# [Service]
# LimitNOFILE=65535
# LimitNPROC=4096
# LimitCORE=0
systemctl daemon-reload && systemctl restart myapp
systemctl show myapp -p LimitNOFILE -p LimitNPROC # 确认服务实际拿到的限制
systemctl status myapp | grep -i limit # 或从状态输出里的资源段核对常见项目与判读
| 项目 | 含义 | 注意点 |
|---|---|---|
| nofile | 单进程可打开的文件描述符数 | 过低表现为 too many open files |
| nproc | 单用户可创建的进程/线程数 | 过紧会让服务 fork 失败 |
| core | core 文件大小上限 | 设 0 表示不生成，利于省磁盘 |
| memlock | 可锁定内存上限 | 数据库等应用常需要放开 |
| soft 与 hard | 软限制与硬限制 | 软限制不能超过硬限制，改软限制上限需先改硬限制 |
limits.conf 对 systemd 服务默认不生效：服务没有 PAM 会话，改完配置文件重启服务仍然继承旧限制，这是『文件配了但服务还是报 too many open files』的典型原因。
给 * 通配所有用户调大 nofile 前先核对内核 fs.file-max：全局上限不足时单个用户配得再大也起不到作用，关键用户单独配置更稳妥。