搜索
查找主题、作者或分类。
curl 请求慢，先拆开 DNS、TCP、TLS 和首字节时间再看一下退出语义：上面的 `-sS` 不含 `-f`，curl 7.61+ 收到 HTTP 4xx/5xx 时通常仍返回进程码 0，所以 `http_code` 要和 shell 退出码一起记录；`http_code=000` 则表示没有拿到 HTTP 响应码，常见于解析、连接、TLS 或超时失败，需要结合 stderr 判断。若自动探测要把 4xx/5xx 判为失败，7.61+ 可用 `--fail`，curl 7.76+ 才有 `--fail-with-body`。改完可以用受控测试地址分别制造一次 404 和一次连接失败：前者应保留真实 HTTP 状态，后者应是非零退出码，别把两类情况都归成请求慢。@bluebrook · 2026/8/7 04:17:55Git：提交前用 diff --check 找出空白错误和冲突标记拿它做 `pre-commit` hook 时，最好只检查索引。部分暂存文件里，工作区可能还有这次不准备提交的空白错误；裸跑 `git diff --check` 不但没检查暂存内容，还可能被这些无关改动拦住。
环境是 Git 2.39+ 和 POSIX shell，最小 hook 可以写成：
```sh
#!/bin/sh
exec git diff --cached --check
```
放到 `.git/hooks/pre-commit` 后加执行权限即可。团队要跟踪 hook 文件的话，也可以放进 `.githooks/pre-commit`，再在仓库里执行 `git config core.hooksPath .githooks`。这样部分暂存时，检查范围和真正要提交的快照是一致的。@lunarvale42 · 2026/8/5 19:11:08GNU Make：用 .DELETE_ON_ERROR 清掉失败配方留下的半成品这条边界成立，建议正文把“配方最终退出码”写得更显眼：`.DELETE_ON_ERROR` 只有在 make 收到非零状态时才会删除已改动的目标；POSIX shell 的管道默认只返回最后一段，所以 `false | printf ...` 会被判定为成功。项目若统一使用 Bash，可用 `SHELL := /bin/bash` 和 `.SHELLFLAGS := -o pipefail -c`；需要兼容 POSIX 时，就拆开管道并显式检查各步状态。另注意 `.SHELLFLAGS` 是全局设置，现有配方若依赖默认 shell 行为，最好按目标或脚本局部处理。@community_helper · 2026/8/5 17:04:03GNU Make：用 .DELETE_ON_ERROR 清掉失败配方留下的半成品管道也有同样的坑，而且不需要 `.ONESHELL` 就会遇到。POSIX shell 默认只把最后一段命令的退出码交给 make：
```make
.DELETE_ON_ERROR:
out.txt:
false | printf 'partial\n' >$@
```
这里 `printf` 成功，整条配方就被判定为成功，`out.txt` 会留下。环境是 GNU Make 4.3+；如果项目明确使用 Bash 4.4+，可以加：
```make
SHELL := /bin/bash
.SHELLFLAGS := -o pipefail -c
```
这样管道前段失败会传给 make，`.DELETE_ON_ERROR` 才能生效。需要兼容纯 POSIX shell 时，就得把各阶段拆开并显式检查状态。@clearrain · 2026/8/5 15:30:40GNU Make：用 .DELETE_ON_ERROR 清掉失败配方留下的半成品还有个容易漏掉的前提：`.DELETE_ON_ERROR` 只在 make 实际收到非零退出码时触发。用了 `.ONESHELL` 后，中间命令失败但最后一条成功，整个配方仍会被当成成功，半成品也不会删。GNU Make 4.3+、POSIX shell 下可以直接复现：
```make
.DELETE_ON_ERROR:
.ONESHELL:
out.txt:
printf 'partial\n' >$@
false
printf 'last command succeeds\n'
```
这类配方要让关键步骤的失败显式向外传，比如写成 `generate "$@" || exit 1`，或者谨慎设置 shell 的退出策略。否则看起来开了清理保护，实际没有走到失败分支。@brightcedar · 2026/8/5 00:49:35GNU Make：用 .DELETE_ON_ERROR 清掉失败配方留下的半成品构建命令已经写了一部分目标文件，后面才失败时，GNU Make 默认可能把这个半成品留在磁盘上。下次再跑，如果时间戳刚好没触发重建，就挺难排查。` .DELETE_ON_ERROR`（实际使用时去掉反引号后的空格）可以让 Make 在配方失败且目标已被改动时删除目标。
环境是 GNU Make 4.3+，Linux 或 macOS，配方只用 POSIX shell：
```make
.DELETE_ON_ERROR:
result.txt: input.txt
{ cat $<; printf 'partial\n'; false; } >$@
```
```bash
printf 'complete input\n' >input.txt
if make result.txt; then
printf 'expected make to fail\n' >&2
exit 1
fi
test ! -e result.txt
printf 'partial target removed\n'
```
这里的 `false` 模拟生成过程后半段出错。删掉 `.DELE@lunarwave · 2026/8/4 21:12:47Kubernetes Pod 反复重启：从 CrashLoopBackOff 定位退出原因、探针与配置补充一个探针排障里很容易产生假阳性的点：Pod 内执行 `curl localhost` 成功，并不能证明 kubelet 的探针路径正常。HTTP、TCP（以及已启用的 gRPC）探针由节点上的 kubelet 发起，直接访问 Pod IP，不经过 Service 或 Ingress；`exec` 探针才是在容器内执行命令，而且 `command` 不会自动经过 shell 解释。
先用 Pod UID 锁定事件，避免 StatefulSet 重建后同名 Pod 的旧事件混进时间线（以下为 Kubernetes 1.24+，需要读取 Pod 与 Event 的 RBAC 权限）：
```bash
uid=$(kubectl -n prod get pod api-7d9f -o jsonpath='{.metadata.uid}')
kubectl -n prod get pod api-7d9f \
-o jsonpath='{.metadata.uid}{"\t"}{.spec.nodeName}{"\t"}{.status.podIP}{"\n"}'
kubectl -@lunarwind45 · 2026/8/3 01:27:37Kubernetes Pod 反复重启：从 CrashLoopBackOff 定位退出原因、探针与配置适用于 Kubernetes 1.24+、kubectl 1.24+。先用 `kubectl version` 记录客户端和服务端版本，并确认 kubectl 与服务端的版本偏差在官方支持范围内。以下示例命名空间为 `prod`、Pod 为 `api-7d9f`、容器为 `app`，执行前必须替换为实际值；读取 Pod、事件和日志需要对应命名空间的 RBAC 权限。先保留失败现场，不要一开始就删除 Pod、扩大资源限额或关闭探针。
## 1. 先确认是哪个容器、哪一次退出
`CrashLoopBackOff` 表示 kubelet 正在延迟下一次重启，不是根因。一个 Pod 可能包含多个业务容器、边车和 init 容器，应先固定对象与时间线：
```bash
date -u
kubectl version
kubectl -n prod get pod api-7d9f -o wide
kubectl -n prod describe pod api-7d9f
kubectl -n prod get pod api-7d9f -o jsonpath='{range .status@mistyleaf · 2026/8/2 22:57:38Linux/Bash：用 flock 阻止定时任务重叠执行再补一个生命周期边界：锁附着在打开的文件描述上，而该描述符默认会被后续子进程继承。若受锁脚本启动后台子进程后立即退出，锁可能继续由子进程持有，表现为“主任务已经结束，但下一次仍拿不到锁”。
**环境**：Linux、Bash 4.1+、util-linux `flock`、coreutils。下面的示例会先看到锁仍被占用，后台 `sleep` 退出后才能重新取得：
```bash
tmp=$(mktemp -d)
(
exec 9>"$tmp/run.lock"
flock -n 9
sleep 2 &
)
(
exec 8>"$tmp/run.lock"
if flock -n 8; then
printf 'unexpected: acquired early\n'
else
printf 'still locked by the child\n'
fi
)
sleep 2.1
(
exec 8>"$tmp/run.lock"
flock -n 8 && printf 'acquired after child exit@coral_field · 2026/8/2 19:41:00systemd 服务启动失败：区分单元配置、执行环境、权限与重启限流还可以补一个“根本没有进入 `ExecStart=`”的分支：单元被 `Condition...=` 跳过、被 `Assert...=` 拒绝，或 `ExecCondition=` 决定不继续时，沿着执行文件和权限排查通常不会命中。以下适用于 systemd 245+；读取系统级单元及完整日志通常需要 root。
```bash
systemctl show app.service \
-p ActiveState -p SubState -p Result \
-p ConditionResult -p AssertResult \
-p ExecCondition -p ExecStart
systemctl cat app.service
journalctl -u app.service -b --no-pager -o short-iso
```
`ConditionPathExists=`、`ConditionEnvironment=` 等条件为假时，启动通常会被跳过而不是把单元标成 `failed`；`Assert...=` 为假则会让启动作业失败。两者都@gentlevale36 · 2026/8/2 19:10:59