最准确方式是直接读/proc/[pid]/limits，它反映进程启动时继承或设置的软硬限制，而ulimit仅显示当前shell的软限制，与systemd等服务无关；查系统级上限需用/proc/sys/fs/file-max和file-nr。
直接看 /proc/[pid]/limits 最准，比 ulimit 更真实——因为 ulimit 只反映当前 shell 启动时的设置，而进程一旦运行，它的限制就固化在 /proc 里了。
查当前 shell 的软限制用 ulimit -a
ulimit -a 输出的是当前终端会话继承的软限制值，比如 open files (-n) 1024、max user processes (-u) 4096。这些值可能和你真正关心的服务进程无关，尤其是 systemd 管理的服务（如 nginx、redis），它们不从你的 shell 继承限制。
- 软限制是当前生效值，硬限制才是上限；
ulimit -Sn和ulimit -Hn才能分开看 -
-c（core file size）、-f（file size）单位是 512 字节块，不是 KB，容易误判 -
-s（stack size）、-d（data seg size）单位是 KB，-n和-u才是“个数”
查指定进程的真实限制用 cat /proc/PID/limits
这才是排查线上问题的关键动作。比如发现某个 Java 进程报 “Too many open files”，别急着改 limits.conf，先确认它实际被设成了多少：
linux-sysadmin
下载
Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...
- 用
ps aux | grep java找到 PID，再执行cat /proc/1234/limits - 重点关注
Max open files行里的Soft Limit和Hard Limit - 如果
Soft Limit是 1024，但Hard Limit是 65536，说明进程启动前没调高软限，只靠改硬限没用
查系统级全局限制用 /proc/sys/ 接口
ulimit 是用户级，而内核参数决定整个系统的天花板：
-
cat /proc/sys/fs/file-max：全系统最大可分配文件句柄数 -
cat /proc/sys/fs/file-nr：当前已分配、未使用、最大总数三列，中间那个偏大说明有泄漏风险 - 这个值不受
limits.conf影响，需通过sysctl -w fs.file-max=...或修改/etc/sysctl.conf持久化
配额启用状态必须手动验证，不能默认存在
比如你想查磁盘配额，运行 quota -u alice 却只显示设备名、无数值，大概率是以下任一情况：
- 对应挂载点没在
/etc/fstab中启用usrquota（ext4）或uquota（XFS） - 没运行过
quotacheck -avugm生成aquota.user数据库 - 没执行
quotaon -av激活配额，尤其重启后需重开
真正有效的配额查询，永远要先确认这三步是否走完，否则 quota 命令只会返回 “none” 或空行。
