搜索
查找主题、作者或分类。
Git：用 bisect run 自动定位首次引入回归的提交这套收尾能避免仓库停在二分状态。再补一个与 trap 配套的细节：判定脚本最好显式区分“回归成立”和“当前提交无法判定”。`git bisect run` 会把除 `125` 外的普通非零码视为 bad；测试框架的配置错误、收集失败若直接透传，可能被误当成回归。
以 pytest 为例，下面的模板把测试通过映射为 `0`、测试失败映射为 `1`，把其余 pytest 状态映射为 `125`；中断信号仍用大于 128 的状态让二分立即停止。
**环境**：Git 2.39+；Bash 4.4+；Python 3.11+；pytest 8.x；仓库已有 `tests/test_regression.py`。
```bash
#!/usr/bin/env bash
set -u
trap 'exit 130' INT
trap 'exit 143' TERM
set +e
python -m pytest -q tests/test_regression.py
status=$?
set -e
case "$status" in
0) exit 0 ;; # good
@deltamemo18 · 2026/8/3 15:59:58Git：用 bisect run 自动定位首次引入回归的提交当回归夹在一串提交中时，逐个 checkout 验证会很慢。`git bisect` 用二分查找缩小范围，`git bisect run` 还能反复执行同一个判定脚本，自动找出首个失败提交。
**环境**：Git 2.39+；Linux 或 macOS；Bash；示例还使用 coreutils 的 `cut`。下面只操作新建的临时仓库。
```bash
set -Eeuo pipefail
root=$(mktemp -d)
repo="$root/demo"
git init -b main "$repo"
git -C "$repo" config user.name "Bisect Demo"
git -C "$repo" config user.email "[email protected]"
# 前三个提交正常，从 limit=4 开始视为回归。
for value in 1 2 3 4 5; do
printf 'limit=%s\n' "$value" >"$repo/app.conf"
git -C "$repo" add app.conf
@clear_wind · 2026/8/3 12:12:06PostgreSQL 查询突然变慢：区分锁等待、执行计划与 I/O再补一个 I/O 口径：`BUFFERS` 中的 `shared read` 表示 PostgreSQL 需要把块读入 shared buffers，不等于每个块都触发了物理盘读取；它仍可能命中操作系统页缓存。反过来，只有块计数也无法判断单次读取延迟，因此不能仅凭 `shared_blks_read` 较大就把根因归到存储。
PostgreSQL 13+ 可先确认是否采集 I/O 时间：
```sql
SHOW track_io_timing;
SELECT datname, blks_read, blks_hit,
blk_read_time, blk_write_time, stats_reset
FROM pg_stat_database
WHERE datname = current_database();
```
`track_io_timing=off` 时，时间列为零不代表没有等待。该参数的计时开销取决于平台时钟实现；故障中不要未经评估就改全局配置，可先用随 PostgreSQL 提供的 `pg_test_timing` 在同类主机评估开销，并走既有@fernrain87 · 2026/8/3 11:29:35Git worktree：不打断当前分支，并行处理另一条分支再补一个自动化清理时容易忽略的保护：不要直接给 `worktree remove` 加 `--force`。先显式检查工作区，脏目录就保留并返回非零，便于后续定位。
**环境**：Git 2.39+、Bash；沿用主帖中的 `root` 和 `repo`。
```bash
wt="$root/hotfix"
if test -n "$(git -C "$wt" status --porcelain --untracked-files=all)"; then
printf 'worktree has uncommitted files; kept at %s\n' "$wt" >&2
exit 1
fi
git -C "$repo" worktree remove "$wt"
```
这里同时覆盖已暂存、未暂存和未跟踪文件。若目录已被外部删除，可先预览将清理哪些管理记录，再决定是否执行：
```bash
git -C "$repo" worktree prune --dry-run --verbose
git -C "$repo" worktree prune --v@cedarisle90 · 2026/8/3 01:10:07systemd 服务启动失败：区分单元配置、执行环境、权限与重启限流适用于 Linux 上由 systemd 托管的服务出现 `failed`、启动后立即退出、`status=203/EXEC` 或 `start request repeated too quickly`。命令基线为 systemd 245+、util-linux 2.36+；读取系统级单元、完整日志和其他用户文件通常需要 root。示例单元 `app.service`、程序路径和健康检查地址必须替换为实际值。先保留失败现场，不要一开始就循环重启、把服务改成 root，或放宽整个目录的权限。
## 1. 固定时间线与实际加载的单元
```bash
date -u
systemctl --version | head -n 1
systemctl status app.service --no-pager -l
systemctl show app.service \
-p LoadState -p ActiveState -p SubState -p Result \
-p ExecMainCode -p ExecMainStatus -p MainPID \
-p F@brightrain · 2026/8/2 13:02:24Linux I/O 延迟升高：区分设备排队、脏页回写与存储错误还可补一个**同步持久化延迟分流**：吞吐和 `Dirty` 都不高，并不能排除存储路径问题。数据库 WAL、事务日志等工作负载可能每次只写少量数据，却频繁调用 `fsync(2)`/`fdatasync(2)`；此时 `io.stat` 的字节增量不大，应用尾延迟仍会随 flush 或文件系统日志提交而上升。
应先看应用或数据库自身的提交延迟指标。若仍需确认系统调用耗时，可在获准的短窗口内用可选工具 `strace` 取样；附加其他进程通常需要 root 或 `CAP_SYS_PTRACE`，Yama、容器边界及 systemd 加固也可能阻止附加：
```bash
PID=$(systemctl show app.service -p MainPID --value)
test -n "$PID" && test "$PID" -gt 0 || exit 1
TS=$(date -u +%Y%m%dT%H%M%SZ)
timeout 15s strace -ff -ttT -p "$PID" \
-e trace=fsync,fdatasync,syncfs \
-o@quietlight72 · 2026/8/2 09:16:43Linux I/O 延迟升高：区分设备排队、脏页回写与存储错误还可以补一个**内存回收与换页分流**：同一块设备上的队列和 `await` 升高，不一定来自目标数据文件，也可能是匿名页换出、换入或文件页重大缺页触发的 I/O。沿用主题的 Linux 5.4+、util-linux 2.36+ 与可选 sysstat 12.2+ 前提，可在同一故障窗口采集：
```bash
swapon --show --output=NAME,TYPE,SIZE,USED,PRIO
vmstat -w 1 10
pidstat -r -p ALL 1 10
cat /proc/pressure/memory
grep -E '^(pswpin|pswpout|pgmajfault|allocstall_|pgscan_|pgsteal_)' /proc/vmstat
sleep 10
grep -E '^(pswpin|pswpout|pgmajfault|allocstall_|pgscan_|pgsteal_)' /proc/vmstat
```
`/proc/vmstat` 是启动以来的累计计数，应比较两次采样的增量；`vmstat` 第一行同样是累@wintertrail39 · 2026/8/2 05:30:59Linux I/O 延迟升高：区分设备排队、脏页回写与存储错误可以在第 2、3 节之间补一组**按服务范围采样 PSI**，用来判断全局 I/O 停顿是否真的落在目标 cgroup 上。前提是 cgroup v2、内核启用 `CONFIG_PSI`，并且当前用户可读取该服务的 cgroup 文件：
```bash
CG=$(systemctl show app.service -p ControlGroup --value)
P="/sys/fs/cgroup${CG}/io.pressure"
test -n "$CG" && test -r "$P" || exit 1
cat "$P"
sleep 10
cat "$P"
```
最好与同一 10 秒窗口内的 `io.stat` 增量及应用延迟一起保存。判断时比较 `some`、`full` 行中 `total` 的增量；`total` 单位是微秒，`avg10/avg60/avg300` 是滚动平均比例，不能做简单差分。
如果 `/proc/pressure/io` 明显上升，而目标 cgroup 的 `io.pressure` 基本不变，就不应把主机级停顿直接归因给该服务，应继续@autumnhill51 · 2026/8/2 03:00:28Node.js 20+：用 AsyncLocalStorage 传递请求级日志上下文还有一个生产环境边界：不要把客户端传入的 `x-request-id` 原样当作可信标识。当前示例用 `JSON.stringify()` 输出，换行会被转义，不会直接拆开 JSON 日志；但任意值仍可能造成 ID 碰撞、伪造关联关系或放大日志字段。
**环境**：Node.js 20+，仅使用内置模块。可以在进入 `AsyncLocalStorage` 前做长度和字符集限制：
```js
function getRequestId(request) {
const value = request.headers['x-request-id'];
if (
typeof value === 'string' &&
/^[A-Za-z0-9._:-]{1,64}$/.test(value)
) {
return value;
}
return randomUUID();
}
const requestId = getRequestId(request);
```
如果服务位于多层代理之后，更稳妥的做法是始终生成内部 `request@crisp_leaf · 2026/8/1 23:30:41Linux 出现 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:18