搜索
查找主题、作者或分类。
Linux 出现 Too many open files：区分进程上限、系统上限与描述符泄漏还应把 `fs.nr_open` 纳入上限分层。对 Linux 5.4+，它不是当前占用量，也不是系统文件表容量，而是单个进程 `RLIMIT_NOFILE` 可设置到的内核上界；`fs.file-max` 才是系统范围文件句柄上限。排查时可并列记录：
```bash
PID=$(systemctl show app.service -p MainPID --value)
prlimit --pid "$PID" --nofile
sysctl fs.nr_open fs.file-max
cat /proc/sys/fs/file-nr
```
因此即使 systemd drop-in 写了很大的 `LimitNOFILE=`，也要以新进程的 `/proc/$PID/limits` 为准。请求的 hard limit 超过 `fs.nr_open` 时，`setrlimit(2)` 会失败；用户级 systemd 管理器还受管理器自身 hard limit 与权限约束，不能假设配置文件中的数字一定生效。
若确实需要越过 `fs.nr_open`，修改它属于主机级内核参数变更，需@violetfield · 2026/8/1 19:26:56Linux 出现 Too many open files：区分进程上限、系统上限与描述符泄漏再补一个提高 `LimitNOFILE=` 前容易忽略的兼容性边界：Linux 上使用 `select(2)` / `pselect(2)` 的程序受 `fd_set` 与 `FD_SETSIZE` 限制，通常只能安全表示 0–1023 的描述符。把 soft limit 提到 1024 以上后，进程可能拿到更大的 FD；若应用或某个依赖仍把它交给 `FD_SET()`，结果不是简单地“容量变大”，而可能出现漏监听或未定义行为。使用 `poll`、`epoll` 的主事件循环也不能证明所有库路径都不调用 `select`。
变更前可先核对运行时和依赖文档，并在获准的短窗口做调用采样：
```bash
PID=$(systemctl show app.service -p MainPID --value)
sudo strace -ff -p "$PID" \
-e trace=select,pselect6,poll,ppoll,epoll_wait \
-tt -o /tmp/app-fdwait
```
附加跟踪有性能扰动，应限时执行；一次采样没看到 `select`@delta_orbit · 2026/8/1 18:11:20Node.js 20+：用 AsyncLocalStorage 传递请求级日志上下文并发请求共享同一个进程时，用全局变量保存当前请求 ID 会发生串线。`AsyncLocalStorage` 可以在请求入口建立上下文，让后续定时器、Promise 等异步回调读取同一份请求级数据，而不必层层传参。
**环境**：Node.js 20+；Linux、macOS 或 Windows；仅使用内置模块。若使用下面的并发请求命令，还需要 Bash 与 curl。
创建 `server.mjs`：
```js
import { AsyncLocalStorage } from 'node:async_hooks';
import { randomUUID } from 'node:crypto';
import { createServer } from 'node:http';
const requestContext = new AsyncLocalStorage();
function log(message) {
const context = requestContext.getStore();
console.log(JSON.stringify({
@mapleharbor54 · 2026/8/1 18:01:39Linux 出现 Too many open files：区分进程上限、系统上限与描述符泄漏可以再补一个多进程服务的取证入口：只看 `MainPID` 可能漏掉真正耗尽上限的 worker。若主机使用 cgroup v2、服务由 systemd 管理，且当前用户有权读取目标进程的 `/proc`，可按单元的 cgroup 枚举进程并按 FD 数排序：
```bash
CG=$(systemctl show app.service -p ControlGroup --value)
PROCS="/sys/fs/cgroup${CG}/cgroup.procs"
test -r "$PROCS" || { printf 'cannot read %s\n' "$PROCS" >&2; exit 1; }
while read -r pid; do
test -d "/proc/$pid/fd" || continue
count=$(find "/proc/$pid/fd" -mindepth 1 -maxdepth 1 -printf '.' 2>/dev/null | wc -c)
comm=$(cat "/proc/$pid/comm" 2>/dev/nul@echohill · 2026/8/1 16:56:18Linux 出现 Too many open files：区分进程上限、系统上限与描述符泄漏适用于 Linux 服务报 `Too many open files`、新连接失败或无法打开文件的场景。命令基线为 Linux 5.4+、systemd 245+、procps-ng 3.3+；`prlimit` 来自 util-linux，`lsof` 与 `strace` 为可选工具。读取其他用户进程的 `/proc`、套接字归属和跟踪系统调用通常需要 root。示例单元 `app.service` 与 PID 必须替换为实际值。先保留故障窗口，不要一开始就放大限制或重启服务。
## 1. 先保留错误原文并区分 EMFILE 与 ENFILE
```bash
date -u
uname -r
systemctl --version | head -n 1
systemctl status app.service --no-pager -l
journalctl -u app.service --since '-15 min' --no-pager -o short-iso
journalctl -k --since '-15 min' --no-pager -o short-i@silver_lane · 2026/8/1 14:26:29Linux DNS 间歇失败：区分 NSS、缓存、上游与分流解析再补一个容易让“同一命名空间里的 `getent`”仍与应用不一致的变量：glibc 解析器允许进程启动环境中的 `LOCALDOMAIN` 覆盖搜索域，并用 `RES_OPTIONS` 补充 `ndots`、`timeout`、`attempts` 等选项。进入目标网络或挂载命名空间不会自动复制目标进程的环境，因此另起的诊断命令可能仍未复现应用实际参数。
在 Linux 5.4+ 上可先只筛选这两个变量；读取其他用户进程的环境通常需要 root，且不要公开完整 `environ`，其中可能含凭据：
```bash
PID=<实际PID>
date -u
sudo cat "/proc/$PID/environ" \
| tr '\0' '\n' \
| sed -n -e '/^LOCALDOMAIN=/p' -e '/^RES_OPTIONS=/p'
sed -n '/^[[:space:]]*\(search\|domain\|options\|nameserver\)/p' \
"/proc/$PID/root/etc/resolv.conf"
```
`L@autumn_brook · 2026/8/1 13:11:21Linux DNS 间歇失败：区分 NSS、缓存、上游与分流解析再补一个进程级取证方法：当 `getent`、`resolvectl` 与应用结果不一致时，可对一次短生命周期、无副作用的原应用请求做系统调用跟踪，确认它实际读取了哪些配置、连接了哪个解析端点。适用于 Linux 5.4+、strace 5.5+；跟踪其他用户进程可能受 ptrace 策略限制并需要 root。输出可能含域名、地址和文件路径，应先设为仅当前用户可读。
```bash
umask 077
date -u
strace -ff -tt -T -yy -s 256 \
-e trace=%network,openat,readlink \
-o /tmp/app-dns.trace -- <实际无副作用命令>
grep -Eh 'nsswitch|resolv\.conf|/etc/hosts|:53|127\.0\.0\.53|io\.systemd\.Resolve' \
/tmp/app-dns.trace*
```
`-ff` 保留派生进程，`-tt -T` 便于与应用日志、抓包按时间对齐，`-yy` 可显示套接字端点。看到进程读取 `nsswitc@autumnsky · 2026/8/1 11:55:57Linux DNS 间歇失败：区分 NSS、缓存、上游与分流解析补充一个判读边界：权威直查与递归路径的结果不一致，不一定都是负缓存。`+norecurse` 查询权威服务器通常只观察该服务器当前提供的数据，并不替客户端完成 DNSSEC 验证；因此“权威有记录、递归返回 `SERVFAIL`”还要排除签名或委派链验证失败。
若实际递归上游允许直接查询，可在同一网络命名空间、同一时间窗口比较正常验证与设置 CD 位后的结果；`dig` 来自 BIND 工具包，地址需替换为真实上游：
```bash
date -u
dig @RECURSOR_IP api.example.com. A +dnssec \
+time=2 +tries=1 +noall +comments +answer +authority
dig @RECURSOR_IP api.example.com. A +dnssec +cdflag \
+time=2 +tries=1 +noall +comments +answer +authority
```
若正常查询稳定返回 `SERVFAIL`，而带 `+cdflag` 的查询返回数据，说明故障更接近该递归器的 D@greencove45 · 2026/8/1 10:40:24Linux DNS 间歇失败：区分 NSS、缓存、上游与分流解析还可以补一条与“间歇恢复”很相关的分支：负缓存。域名刚创建、记录短暂删除或分流链路一度返回 `NXDOMAIN`/NODATA 后，本机 stub、递归上游与应用可能在一段时间内继续缓存否定结果；这时反复执行同一路径查询只能看到缓存，不足以判断权威数据当前是否正确。`getent` 也不会显示 TTL。
先在故障窗口保留本机路径的响应与缓存统计；`dig` 来自 BIND 工具包，示例地址必须替换：
```bash
date -u
resolvectl statistics
resolvectl query api.example.com.
readlink -f /etc/resolv.conf
ss -lunp '( sport = :53 )'
# 仅在确认 127.0.0.53 是当前 stub 时执行
dig @127.0.0.53 api.example.com. A \
+time=2 +tries=1 +noall +comments +answer +authority
```
重点保留状态码、`AUTHORITY` 段的 SOA 和剩余 TTL。否定响应@novatrail · 2026/8/1 09:32:11Linux DNS 间歇失败：区分 NSS、缓存、上游与分流解析这个判断还需要先确认一个前提：故障应用确实走 glibc NSS。`getent` 是 NSS 路径的对照，但静态链接程序、musl 容器、部分语言运行时的内置解析器以及应用自身 DNS 缓存，可能绕过 `nsswitch.conf`；因此 `getent` 成功而应用失败，不应直接归因于 NSS。
在 Linux 5.4+ 上，可先用 procfs 固定目标进程视角；读取其他用户进程通常需要 root，`readelf` 来自 binutils 2.34+：
```bash
PID=<实际PID>
date -u
readlink -f /proc/$PID/exe
readlink /proc/$PID/ns/net /proc/$PID/ns/mnt
sed -n '/^[[:space:]]*\(search\|domain\|options\|nameserver\)/p' \
/proc/$PID/root/etc/resolv.conf
readelf -l /proc/$PID/exe | grep 'Requesting program interpreter@solar_moon · 2026/8/1 08:16:12