必须同步调整用户级进程上限、systemd服务LimitNOFILE和系统级fs.file-max三层限制，缺一不可；ulimit -n仅临时生效于当前shell，永久生效需配置limits.conf（配软硬限制+PAM加载）、systemd service文件及sysctl.conf。
ulimit -n 设置不了永久生效的文件打开数限制，它只影响当前 shell 及其子进程。真正要让“Too many open files”不再报错，必须同步调整三层：用户级进程上限、systemd 服务限制、系统级总池。
查清当前软硬限制和系统总池
别猜，先看真实值：
-
ulimit -Sn和ulimit -Hn—— 分别是当前会话的软限和硬限；普通用户只能把软限设到 ≤ 硬限的值 -
cat /proc/sys/fs/file-max—— 整个系统能分配的 fd 总数，不是建议值，是硬天花板 -
cat /proc/sys/fs/nr_open—— 单个进程理论上最多能拿到多少 fd（内核级硬限），nofile不能超它
如果 ulimit -Hn 卡在 4096，大概率是 nr_open 或 limits.conf 没加载成功，不是数字写小了。
/etc/security/limits.conf 必须满足三个条件才生效
这个文件不是“保存就起效”，它依赖 PAM 登录流程加载：
- 配置格式必须严格：
www-data soft nofile 65535和www-data hard nofile 65535要分开两行，空格不能用 Tab - /etc/pam.d/common-session（Ubuntu/Debian）或 /etc/pam.d/system-auth（RHEL/CentOS）里必须有未注释的：
session required pam_limits.so - 改完必须全新登录（SSH 断开重连、GUI 登出再进），
su - www-data不触发完整 PAM session，不会加载新限制
验证方式：登录后立刻执行 ulimit -n 和 ulimit -Hn，两个都得是目标值。
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
systemd 服务必须单独配 LimitNOFILE
nginx、redis、node.js 这类用 systemctl start 启的服务，完全无视 limits.conf。它们走 systemd 的资源控制路径：
- 不要编辑原始 unit 文件（会被包管理器覆盖），运行：
sudo systemctl edit nginx.service - 写入：
[Service] LimitNOFILE=65535
- 执行：
sudo systemctl daemon-reload && sudo systemctl restart nginx - 验证：
systemctl show nginx --property LimitNOFILE，输出应为LimitNOFILE=65535
注意：如果服务主进程以 root 启动、worker 降权为 www-data，LimitNOFILE 仍必须设在 service 定义里，不能指望该用户的 limits.conf。
别漏掉 fs.file-max 内核总池
单个进程上限提上去了，但系统全局池太小（比如默认 32768），多个进程一起开句柄，照样报 “Too many open files”：
- 临时调大：
sudo sysctl -w fs.file-max=1048576 - 永久生效：往
/etc/sysctl.conf追加一行：fs.file-max = 1048576，再运行sudo sysctl -p - 别设太高——超过 200 万可能引发内核内存压力；一般 100 万足够支撑千并发 HTTP 服务
- 顺手检查当前使用量：
cat /proc/sys/fs/file-nr，输出三列，第三列是file-max，第二列是已用数
最常被忽略的是：你改了所有配置，但没重启对应服务进程，旧进程仍卡在 1024；或者验证时没切到目标用户、没确认是哪个进程在报错。
