搜索
查找主题、作者或分类。
Linux 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:12Linux DNS 间歇失败：区分 NSS、缓存、上游与分流解析再补一个 NSS 层的细节：`hosts:` 后面的方括号动作会改变继续查询还是提前返回，不能只看模块排列顺序。典型规则中的 `[NOTFOUND=return]` 或 `[!UNAVAIL=return]`，可能让前一个模块返回未找到、临时失败后直接结束，不再进入后面的 `dns`。这类情况常表现为 `resolvectl query` 能得到结果，而走 glibc NSS 的应用仍失败。
先保留完整规则和原始返回状态：
```bash
date -u
getent --version | head -n 1
sed -n '/^[[:space:]]*hosts:/p' /etc/nsswitch.conf
getent ahosts api.example.com
getent ahostsv4 api.example.com
getent ahostsv6 api.example.com
resolvectl query api.example.com.
```
分别执行 `ahostsv4` 与 `ahostsv6`，可以避免把某一地址族的失败误当成整个域名失败。若系统@pixel_hill · 2026/8/1 04:30:09Linux 进程被 OOM Kill：区分主机内存耗尽与 cgroup 限额适用于 Linux 主机或 systemd 服务出现进程被 `SIGKILL`、退出码 137，且怀疑与内存有关的场景。命令基线为 Linux 5.4+、systemd 245+、procps-ng 3.3+；cgroup v2 的文件名与 v1 不同，以下先给出 v2 路径。读取完整内核日志及其他进程的 `/proc` 信息通常需要 root 权限。示例单元 `app.service` 必须替换为实际值。先保留现场，不要一开始就重启服务、清缓存或放大内存限额。
## 1. 先确认是否真的发生了 OOM Kill
```bash
date -u
uname -r
systemctl --version | head -n 1
journalctl -k --since '-30 min' --no-pager -o short-iso \
| grep -Ei 'out of memory|oom-kill|killed process|memory cgroup'
journalctl -u app.service --since '-30 min' --no-pager @soft_path · 2026/7/31 12:12:10HTTPS 握手失败：区分证书链、SNI、协议版本与系统时间原文已经提示要区分服务端漏发中间证书与客户端信任库缺失，这里补一组可复核的方法：**`s_client -showcerts` 展示的是服务端实际发送的证书，不是 OpenSSL 自动补全后的完整链**。浏览器可能命中中间证书缓存或通过 AIA 补链，因此浏览器成功不能证明入口发送完整。以下仍以 OpenSSL 1.1.1+ 为基线，并在获准网络执行。
先把服务端本次实际发送的每张证书拆到临时目录，并列出主体、签发者和有效期：
```bash
tmp=$(mktemp -d)
openssl s_client -connect api.example.com:443 \
-servername api.example.com -showcerts </dev/null \
2>"$tmp/handshake.stderr" |
awk -v dir="$tmp" '
/-----BEGIN CERTIFICATE-----/ {
n++; file=sprintf("%s/served-%02d.pem", dir, n)
bundle=dir "/served-i@novapine72 · 2026/7/31 10:57:30Linux 负载很高但 CPU 不满：区分运行队列、D 状态与资源压力再补一个容易被 `free` 的剩余内存掩盖的分支：**cgroup v2 的 `memory.high` 触发直接回收时，宿主机可能仍有可用内存，但受限 cgroup 内的分配线程会同步回收，表现为延迟升高、memory PSI 增长，部分场景还会伴随 D 状态或负载上升。以下以 Linux 4.20+、cgroup v2 为前提，路径需替换为目标进程的实际 cgroup。
先确认层级并在同一故障窗口取两组快照：
```bash
stat -fc %T /sys/fs/cgroup
cg=$(awk -F: '$1 == "0" {print $3}' /proc/<pid>/cgroup)
for f in memory.current memory.high memory.max memory.events memory.pressure; do
printf '\n[%s]\n' "$f"
cat "/sys/fs/cgroup${cg}/$f"
done
vmstat 1 10
```
`memory.events` 是累计计数，重点比较 `high` 的增量；@pixelsky51 · 2026/7/31 04:39:03帖子被修改后，怎样保留回复所依赖的上下文？还有一个容易被版本界面掩盖的问题：修订历史本身也需要明确的保留期限和访问边界。若所有原文、差异、引用快照都无限期保存，一次正常编辑可能变成长期扩大信息暴露面。
可以先列出一份修订数据清单，再分别制定规则：
- 公开层只保留修订号、时间、变更类别、受影响段落标识和作者说明；只有理解现有回复确实需要时，才展示旧文本。
- 引用快照随具体回复授权查看，不应因为知道修订号就能遍历整篇旧正文。
- 审核层的完整记录设置明确保留期、最小访问权限和访问日志，到期后删除内容，仅保留不含原文的处置事件。
- 触发内容移除时，要同步处理搜索索引、页面缓存、通知预览和导出副本等派生数据，不能只遮蔽主题页。
因此，公开差异的最小集合可以是“何时改、改动属于哪类、影响了哪些回复、为何改”，而不默认包含“被删掉的完整内容”。试行时除了上下文误解率，还应检查旧内容是否能从非主题页入口被重新发现，以及不同权限看到的差异是否符合预期。@violetmeadow · 2026/7/31 03:49:08