“too many open files”报错源于进程打开的文件描述符超限；需分场景调整：临时用ulimit命令、用户级永久改/etc/security/limits.conf、systemd服务配limitnofile、系统级调fs.file-max。
遇到“Too many open files”报错，本质是进程打开的文件描述符（fd）超出了系统限制。ulimit 控制单个进程能使用的最大 fd 数，修改它需分场景处理：临时调试、用户级永久生效、systemd 服务、以及系统总上限。
临时调高当前终端的限制
适合快速验证或测试，退出终端即失效：
- 查看当前软限制：
ulimit -Sn - 查看当前硬限制：
ulimit -Hn - 把软限制设为 65535（不能超过硬限制）：
ulimit -Sn 65535 - 若硬限制太低且你有 root 权限，可同步提升：
sudo sh -c 'ulimit -Hn 65535; exec bash'（注意：普通用户无法自行提高硬限制）
永久生效：改 /etc/security/limits.conf
这是最通用的用户级永久方案，但必须满足三个条件才真正生效：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 在文件末尾添加两行（以所有用户为例）：
* soft nofile 65535* hard nofile 65535
如只针对某用户（如 nginx），把*换成用户名；root 用户建议显式配置，避免被发行版策略绕过 - 确认 PAM 加载了 limits 模块：检查
/etc/pam.d/common-session（Debian/Ubuntu）或/etc/pam.d/system-auth（RHEL/CentOS）中存在session required pam_limits.so - 用户必须重新登录（SSH 断开重连、图形界面注销再登录），
su - user不一定触发完整 PAM session，不保证生效
systemd 服务必须单独配 LimitNOFILE
哪怕 limits.conf 已改，systemd 启动的服务默认不读取它。必须在服务单元中显式声明：
- 编辑服务配置：
sudo systemctl edit nginx.service（或你的服务名） - 写入：
[Service]LimitNOFILE=65535 - 重载并重启：
sudo systemctl daemon-reload && sudo systemctl restart nginx - 也可全局设置：编辑
/etc/systemd/system.conf，在[Manager]下加DefaultLimitNOFILE=65535
别漏掉系统级总上限 fs.file-max
这是内核允许整个系统分配的 fd 总数，所有进程共用。如果并发很高，这个值也可能成为瓶颈：
- 查看当前值：
cat /proc/sys/fs/file-max - 临时提高（重启失效）：
sudo sysctl -w fs.file-max=1048576 - 永久生效：往
/etc/sysctl.conf追加fs.file-max = 1048576，再执行sudo sysctl -p
